ArcSight Logger in Two Hours - V0.1
- Pavan Raja
- Apr 8, 2025
- 23 min read
Summary:
The breakdown of each query described provides a clear understanding of how to extract actionable insights from complex network traffic data using filters tailored for different aspects of network activity or device configurations. Here's a summary of the queries provided, including their descriptions and potential applications:
1. **Top Device Vendors**: Lists the top device vendors based on available data, useful for understanding which manufacturers are most commonly associated with the devices in the dataset. This can help identify popular hardware vendors that might need special attention or optimization.
2. **Top Device Products**: Identifies the top device products reported by the devices. This helps to understand which specific models or types of devices are being used, which is crucial for inventory management and potential upgrades or replacements.
3. **Versions of Connectors Reporting into Logger**: Shows the versions of connectors that report information into the logger from the devices. This can be important for ensuring compatibility between different software versions and hardware platforms, aiding in version control and troubleshooting.
4. **TippingPoint Events per Hour**: Provides a count of TippingPoint events occurring every hour across all instances. Useful for monitoring security incidents or performance metrics over time, allowing quick response to potential threats or system malfunctions.
5. **What’s Coming into Logger?**: Lists the top names of data sources that are being logged or monitored in the system. This helps in understanding which systems are actively contributing data to the logging mechanism, useful for auditing and ensuring all relevant devices are covered.
6. **Failed Logins by User**: Identifies users who have failed login attempts using specific criteria related to authentication failures and non-null usernames. This is crucial for security audits and can help in identifying brute force attacks or compromised accounts.
7. **Top NetFlow Destination Ports**: Displays the most common destination ports used for Cisco NetFlow devices, specifically those with a port number greater than 0. Helps in network traffic analysis and understanding which services are heavily utilized on the network.
8. **Products with Changes Recently**: Lists products that have had modifications made recently based on specific behavior patterns in the system. Useful for tracking updates or changes to devices, ensuring compliance or identifying potential issues related to firmware or software updates.
9. **Example of Regex Query**: Demonstrates a query using regular expressions to filter data related to Zara from a broader dataset involving CEF entries and devices like Unix. This can be adapted for similar use in other datasets where specific patterns need to be identified.
10. **Top 20 Products by Event Count (Non-aggregated)**: Lists the top 20 device products based on event count without considering aggregation or grouping. Useful for performance monitoring and understanding which devices are generating the most events, indicating potential bottlenecks or high activity areas.
11. **Top 20 Products by Event Count, Aggregation Used**: Similar to above but shows results after aggregating events per product for a more detailed analysis. This can help in performance tuning and identifying which products are most active across the network, aiding in resource allocation and optimization.
12. **Events by Each Source (Sorted)**: Sorts the total number of events from each source in descending order based on their occurrence. Useful for understanding where the majority of activity is coming from, enabling focused monitoring or troubleshooting efforts.
13. **Blue Coat Bytes In and Out**: Queries related to data transfer volumes (BytesIn and BytesOut) for devices belonging to Blue Coat, specifically excluding entries that contain "wind" in the destination hostname. This helps in isolating specific traffic patterns and can be crucial for bandwidth management or security audits.
Each of these queries is designed to provide specific insights from a large dataset based on different criteria, allowing users to filter and analyze data according to their needs. The provided commands are used specifically for analyzing network traffic data from Blue Coat devices, with each command tailored to extract particular types of information relevant to network monitoring and troubleshooting.
Details:
This document contains confidential information belonging to Hewlett-Packard Company or its affiliates (collectively "HP"), intended solely for evaluation purposes. The recipient agrees to maintain this information as confidential and not reproduce or disclose it to others without written authorization from HP. Confidentiality does not apply if the information was publicly known before receipt, becomes public knowledge through no fault of the recipient, or is rightfully received from a third party without restrictions. The document may include details about current HP products, sales, and service programs that could be modified or discontinued by HP at its discretion. Although HP has made efforts to ensure the accuracy and relevance of the information provided, it does not guarantee its accuracy or completeness. This document is offered for informational purposes only with no liability assumed by HP in case of use. The term "solution" refers to the products and services proposed in this document, and further information may be required for project development.
The provided material outlines a comprehensive guide for using ArcSight Logger, an enterprise-level log management software designed to secure data, enforce compliance, and combat cybercrime. The document begins by clarifying that the use of terms like "partner" or "partnership" does not imply a formal legal partnership but rather a collaborative relationship between parties. It emphasizes that while the product or services proposed may be beneficial, they do not guarantee specific outcomes or meet all individual requirements.
The guide includes several sections detailing various aspects of Logger usage:
Overview and interface introduction (4-14)
Connecting to the user interface and basic functionalities like searching and analyzing events (15-17)
Configuring systems for specific use cases, such as integrating with Windows Unified Connector (22-24)
Detailed walkthroughs of various use cases including search/analyze, categorization, live feed viewing, dashboard creation, reporting, and more (27-43)
Explanation of pipeline operators and selected examples to enhance event management capabilities.
The document concludes with information about ArcSight Logger as a free downloadable software, suitable for quick deployment and use. It allows users to collect substantial log data with easy setup, offering initial support for 90 days followed by additional services if needed.
ArcSight Logger is a comprehensive log management solution that provides access to all enterprise features for a full 12 months and allows for upgrades at any time during this period. This tool collects data from various sources, processes it according to user requirements, and offers ultra-fast searching capabilities across the collected logs. It serves organizations of all sizes by facilitating faster forensic analysis in IT operations, application development, and cybersecurity, as well as helping them comply with multiple regulations.
ArcSight Logger stands out because it is a universal log management solution that can capture and analyze enterprise-wide log data to address questions from individual teams. Unlike traditional log management tools, ArcSight Logger is not limited by the type of sources it can handle, has unrestricted search/reporting capabilities, and scales easily to become an enterprise-level log management system when needed.
The tool's initial release was based on ArcSight Logger 5.2, with updates made in November 2012 for compatibility with Windows 2008. Any documentation changes or suggestions can be directed to Brian Wolff at hp.com. As of the current models available, Logger can be deployed inside a perimeter firewall with high physical security to protect collected event information and does not require other ArcSight products.
The Logger Appliance is designed to collect and forward syslog and log file events generated by various hardware and software network products. It also seamlessly integrates with ArcSight's Enterprise Security Manager (ESM) for advanced correlation and monitoring of security events. A typical application involves collecting firewall or other data, forwarding a selected subset to ESM for real-time analysis, and optionally storing the raw data for compliance or service level agreement needs.
The Logger Appliance can function as both a data collector and forwarder, directing specific events to ArcSight ESM, and it can also act as a storage solution by holding onto sent events. Additionally, configuring the appliance involves basic network settings such as setting an IP address and default gateway, which are essential for proper operation and accessibility from other devices like workstations.
To configure the Logger Appliance:
1. Log in using default credentials (username: admin, password: password).
2. Use the "help" command to access a list of available commands and their descriptions.
3. Set the IP address by typing "set IP", then inputting the desired settings like IP 10.0.187.38 with netmask 255.255.255.0, verifying it with "show ip".
4. Configure the default gateway using "set defaultgw" and setting it to 10.0.187.1 for interface eth0, checking this configuration with "show defaultgw".
5. Connect from a workstation to verify the configuration by accessing https://10.0.187.38.
Installing a license on the Logger Appliance involves connecting to it via the steps provided in the guide.
The provided instructions outline the process of configuring a system via its user interface. Here's a summary of the steps involved in setting up and configuring various settings on a device accessible at IP address 10.0.187.38:
### License & Update Configuration
1. **Access the Interface**: Navigate to `https://10.0.187.38`. The default credentials are admin/password, though you might need to accept legal agreements first.
2. **Navigate to System Admin**: From the top-level menu bar, select "System Admin".
3. **Go to License & Update**: Within the System section, click on "License & Update".
4. **Upload Update**: Click "Browse" to locate and upload the necessary update file. Then, click "Upload Update".
### Date & Time Zone Configuration
1. **Access System Admin**: From the top-level menu bar, select "System Admin".
2. **Navigate to Network Settings**: Within the System section, click on "Network".
3. **Set Time Zone**: Click the "Change Time Zone" button and choose the appropriate time zone. This action requires a reboot for changes to take effect.
4. **Configure Date & Time**: In the System DNS tab, set up an NTP server or manually input the date and time zone. Save these settings after entering them.
### DNS Settings Configuration
1. **Access System Admin**: From the top-level menu bar, select "System Admin".
2. **Navigate to Network Settings**: Within the System section, click on "Network".
3. **Set DNS Servers and Search Domains**: In the System DNS tab, enter the IP addresses for primary and secondary DNS servers and edit up to 6 search domains. Click "Save" to apply these changes.
### Hosts File Entries Configuration
1. **Access System Admin**: From the top-level menu bar, select "System Admin".
2. **Navigate to Network Settings**: Within the System section, click on "Network".
3. **Set Hosts File Entries**: In the Hosts tab, enter IP addresses and corresponding hostnames in the specified format: ` `.
### Introduction to Logger (Summary)
ArcSight Logger is a log management solution designed for high event throughput efficiency. It seems to be an incomplete summary as it ends abruptly before providing further details about ArcSight Logger's functionalities or features, possibly due to the text being cut off in the provided snippet.
The text discusses "Logger," which is described as software that handles time-stamped text messages, referred to as events. These events can be syslog messages from hosts or lines appended to log files. The system collects and stores these events, supports searching and retrieving them for analysis, and has the option to forward specific events.
Logger is available in two forms: an appliance (a dedicated hardware solution) and software. The appliance-based version is designed for high event throughput, efficient long-term storage, and rapid data analysis due to its optimization for these functions.
The software version of Logger supports installation on platforms with specific specifications, including a VM installation for supported operating systems. ArcSight recommends allocating at least 4 GB RAM per virtual machine (VM) instance for optimal performance. The total memory allocated to active VMs on a server should not exceed the physical memory of the server.
Logger stores time-stamped text messages called events efficiently, compressing raw data but retaining the ability to access unmodified data upon request for forensic or litigation purposes. It supports both structured and unstructured event types, searching them through a unified interface. Logger utilizes ArcSight SmartConnector framework for collecting events, including normalized CEF (Common Event Format) from SmartConnectors.
Multiple Loggers can collaborate in a peer network to handle high volumes of events efficiently, with search queries being distributed across all loggers, thereby scaling the system's capacity to manage large data loads. The syslog standard is mentioned as a basis for event messages but acknowledges its loose definition according to RFC 3164.
This text discusses the benefits of using a Common Event Format (CEF) for interoperability among various technology providers, and how it allows devices to send log or event data in a standardized way. The information provided explains that raw events consist of elements like receipt time, event time, source (host name or IP address), and an unparsed message portion. These events are displayed in a tabular format by the Logger software for easy analysis.
The article then goes on to describe how users can analyze events within Logger. Events can be searched either manually or automatically using terms from the event table. Searches can be based on full-text search, predefined fields, or regular expressions. The Logger supports a flow-based search language that allows for multiple commands in a pipeline format.
By default, queries are executed against the primary data store within Logger, but it is possible to configure the system to distribute these across peer Loggers as well. Queries can be saved either as filters for future use or as Saved Searches for exporting selected events or saving results to files. In version 5.2, these saved searches were enhanced to create customizable dashboards tailored to individual users' needs.
The article also covers the interface and browser requirements for Logger. It states that Logger is compatible with most modern browsers such as Firefox and Internet Explorer. JavaScript and cookies must be enabled, and an Adobe Flash Player plug-in is required for accessing the Logger user interface if using Internet Explorer. The text provides a link to download the plugin from Adobe's website. Additionally, it mentions which browser versions are supported according to the Release Notes document.
Finally, the article explains how to connect to Logger, but there's no specific information provided about this process in the snippet you've given me. If you have any further details or questions on connecting to the Logger, I can provide additional assistance!
The Logger software user interface features a secure connection via SSL, accessible at the URL format https://:. Upon accessing this URL, users are presented with a login screen where they must accept any disclosure before proceeding.
The UI has a consistent navigation band across all pages that includes gauges displaying system statistics and CPU usage details on the Monitor Dashboard. The range of these gauges can be adjusted through the Options page. User-specific information like name is displayed below the statistics, and there are icons to expand or collapse the gauge and logo bar for more screen space.
The top right menu provides links for Help, accessing the Options settings, and logging out. Clicking Help on any page displays context-sensitive online help, while a Search Helper utility assists with search queries. This tool offers history, examples of operators, suggested next steps based on current input, and details about available fields and operators.
The Options page allows users to customize the range on EPS In and EPS Out gauges automatically adjusting it if event rates exceed preset limits. It also enables setting a default start page (home page) for easier access on subsequent logins.
The article outlines various features and functionalities of a Logger software, focusing primarily on its user interface and dashboard capabilities. It explains that users can set specific start pages for their individual accounts via the Options page, which determines which user interface appears after login. Additionally, it covers logging out by clicking the Logout link or having the system automatically log out after a configurable period (15 minutes default).
The article introduces the concept of Dashboards as global dashboards providing summarized event information about the Logger. These dashboards allow users to assemble various search queries and display them in panels such as Search Results and Monitor, which offer at-a-glance status updates on events, receivers, forwarders, storage, CPU, and disk usage. Users can customize these panels according to their specific interests and requirements, enabling a comprehensive view of Logger information.
Moreover, the article describes how to perform searches for stored events using a flow-based search language that supports multiple pipeline format commands. It also mentions the ability to customize the display of search results, such as viewing them in charts. The article concludes by highlighting the ease of use and intuitive interface design of Logger's search capabilities.
The article describes a search query system used in Logger, which allows users to input various types of queries, from simple keyword searches like "hostA.companyxyz.com" to complex expressions involving Boolean logic, indexed fields, and regular expressions. These queries can be constrained to specific device groups and storage groups within the system. The user interface provides auto-suggest functionality for entering queries, suggesting possible matches and field operators, which aids in constructing search terms efficiently.
The article explains how a query is structured: it includes a Query Expression (the conditions used to select or reject events), Time range (the duration during which events are searched), and Field Set (specific fields from the event that should be displayed). It emphasizes the importance of understanding all elements of a query for optimal use of Logger's search capabilities.
To summarize, Logger offers two methods for saving and reusing queries: saved filters (saving just the query expression without time range or field set) and saved searches (including both the query expression and time range). The software also provides several tools to assist with building complex queries:
1. Search Builder: This is a graphical tool that helps in creating search queries using Boolean logic, specifying keywords, field-based conditions, and regular expressions, along with constraints like device groups and storage groups.
2. Regex Helper: Designed for creating regular expressions used within the rex pipeline operator to extract specific fields from events, this tool simplifies the process and minimizes errors.
3. Search Helper: This utility aids in query creation by offering a search history of previously run queries, a search operator history showing previous field usage with the current operator, providing examples related to the latest typed operator, and suggesting next operators based on the input.
The provided text outlines steps for configuring a system, specifically for integrating a Windows Unified Connector with a Logger. Here's a summarized version of the instructions and information presented:
1. **System Filter Usage**: When using a logger, you can utilize system filters which are predefined queries for common events (e.g., unsuccessful login attempts or event counts by source). To use these filters:
Go to Analyze > Search.
Load a Saved Filter and select the desired filter from the list.
Click Load+Close to run the query.
2. **Configuring Logger for Windows Unified Connector Events**:
Access the logger menu, mouse over Configuration, and select Settings > Event Input/Output > Receivers.
Click "Add" and configure a new receiver:
Name it "Windows".
Set Type to "SmartMessage Receiver".
Choose default Encoding and SAVE settings.
The receiver is now configured but not enabled; click the enable icon (which will change from No to a checkmark) to activate it.
3. **Additional Configuration for Connector Appliance**: If your logger supports onboard connectors, navigate to Configuration > Manage Connectors to access connector management and configure the Windows Unified Connector as needed.
This summary provides a streamlined guide to setting up and enabling a connector within a logging system, ensuring that events from a specific source like Windows Unified Connector are correctly received and processed by the Logger.
To add a Microsoft Windows Event Log connector, follow these steps:
1. Click the "add Connector" icon to begin the process.
2. Click "Next."
3. Choose "Microsoft Windows Event Log - Unified" as the connector type.
4. If you're using the Windows Host Browser, skip this step and go to the next steps. Otherwise, choose to enter devices manually.
5. For each host you want to collect events from, click "Add Row."
6. Fill in the required fields: Domain Name (depending on your user account type), Host Name (IP address or hostname), User Name (without domain), and Password.
7. Decide whether to collect security logs by checking the box; default is checked.
8. Select checkboxes for System Logs, Application Logs, etc., according to what you want to monitor.
The provided instructions and descriptions outline the process for setting up a log collection tool called "ArcSight Logger SmartMessage" on a host running Microsoft Windows, specifically focusing on logging failed logon attempts. Here's a step-by-step summary of what to do:
1. **Set Up Application Events:** Decide whether you want to collect application events by unselecting the checkbox if not desired. The default setting is unchecked (false).
2. **Select Microsoft Operating System Version:** Choose the specific version of the Microsoft OS that your host is running on from the provided options.
3. **Set Locale:** Enter the locale code corresponding to your preferred language. Possible values include 'en_US' (United States English), 'ja_JP' (Japanese), 'zh_CN' (Simplified Chinese), 'zh_TW' (Traditional Chinese), and 'fr_CA' (French). The default value is set to 'en_US'.
4. **Install the Software:** Click "next" to proceed with the installation, following all on-screen instructions until it's complete.
5. **Select Destination Type:** In the setup interface of the software, choose "ArcSight Logger SmartMessage" as the destination type for your log data.
6. **Enter Log Configuration Details:** Fill in the "Hostname/IP" with the IP address or hostname of the ArcSight Logger and provide a "Receiver Name." This should match an existing receiver on the logger, named "Windows" in this example.
7. **Configure Event Collection:** Focus on logging failed logon attempts:
Identify the specific event codes related to failed logons: 529 (Unknown user name or bad password), 530 (Account logon time restriction violation), 531 (Account currently disabled), 532 (Account has expired), 533 (User not allowed to logon at this computer), 534 (Insufficient privileges for requested logon type), 535 (Password has expired), 536 (NetLogon component is not active), and 537 (Other logon/authentication failures).
Perform a simple text search within the event logs for entries containing "Security:52", which should help in identifying relevant failed logon attempts.
By following these steps, you can effectively configure your system to capture detailed information about failed logon attempts using ArcSight Logger SmartMessage. This setup is crucial for monitoring and analyzing security events such as failed logins on a Microsoft Windows host.
To summarize this text, let's break down the steps and explanations provided:
1. **Search and Analyze**: The user is instructed to navigate to the ArcSight interface where they can perform a search using specific event codes or IDs for Windows 2008 (4625). However, instead of requiring users to know these exact codes, ArcSight uses categorization to simplify the process by organizing events into categories.
2. **Search Functionality**: The user is shown how to use the search function in ArcSight with two examples: using "Security:529" or for Windows 2008, entering "Microsoft-Windows-Security-Auditing:4625". Both searches return events that meet the criteria and are displayed for further review.
3. **Customizing Results**: The user can customize the display of search results by selecting different field sets, including categories. This is done through a dropdown menu where users can choose to view categorized fields.
4. **Categorization in ArcSight**: The text explains how events are automatically normalized, categorized, and prioritized as they are collected from logging systems. For example, the event "Security:529" is categorized under different fields such as categoryBehaviour (Authentication/Verify), categoryDeviceGroup (Operating System), CategoryObject (Host/Operating System), CategoryOutcome (Failure), and CategorySignficance (Information/Warning).
5. **Modifying Search**: The user can modify the search to focus on specific categories within the authentication process by changing the query from "Security:529" to "/Authentication/Verify AND /Failure". This modification helps in narrowing down the results to events of interest more closely related to authentication failures.
In summary, this text provides a guide for using ArcSight's categorization feature to simplify event searching and analysis, even when dealing with complex security codes specific to different systems like Windows 2008. The categorization helps in organizing and prioritizing the data collected from various logging sources, making it easier for users to focus on relevant information without needing a deep understanding of each system's individual event coding.
In a system designed for handling authentication failures across various vendors, including Microsoft and others like UNIX and Tipping Point, there's now a unified view where all events classified as Authentication Failures are displayed regardless of their origin. The interface has been updated to facilitate quick navigation through the logs by highlighting entries that meet specific criteria when triggered by user actions such as hovering over an entry or clicking on it.
To refine these searches, additional functionality is provided for structured search elements where users can input keywords directly into a free-form text field. For example, typing "Microsoft" under the deviceProduct column narrows down the results to only include events related specifically to Microsoft products. Alternatively, using the ALT-Click option allows insertion of a NOT condition to exclude specific terms from the search.
For future use and organization of these queries, users can save them with customized names, including initials in the description, for easy identification and access under the "Saved Search" radio button. Additionally, field summaries provide a quick overview of relevant information without manual counting, allowing users to focus on specific data points of interest by clicking different values listed within it. This feature helps streamline analysis processes and enhances decision-making efficiency based on pre-defined criteria.
The process outlined involves using a search tool with specific criteria and filters to analyze data, focusing initially on events related to Microsoft products or services after failure conditions are met. Here’s a step-by-step breakdown of what happens next:
1. **Initial Query Setup**: Start by setting up a query that includes the keywords "Microsoft" in either "deviceProduct" or "Failure," and filters for specific security events using "deviceEventClassId = "Security:533"."
2. **Chart Creation**: Automatically generate a chart based on time intervals from the search results, aiming to visually represent trends over time.
3. **Chart Settings Adjustment**: Enhance readability and clarity of the graph by switching the chart type from default to a line graph in the "Chart Settings."
4. **Restoring Saved Search**: Retrieve an earlier saved query configuration to ensure all adjustments or changes are properly accounted for. This involves navigating through tabs like "Saved Searches" and clicking on the relevant icon.
5. **Field Adjustment**: Modify the display fields within the search results by resetting them back to show all available fields, then focusing specifically on "destinationUserName." Configure the time frame to be dynamic over the last hour.
6. **User-Specific Search**: Further refine the query to focus solely on activities related to a particular user identified as "jimmyj" without any other criteria initially applied. Adjust the search to include only entries where "destinationUserName" contains "jimmyj."
7. **Minimize and Filter Data by IP Address**: To narrow down data further, switch the investigation from username-based events to those associated with a specific IP address found in the "deviceAddress" field. Set this filter specifically for the IP "10.1.1.5," revealing related activity across various event feeds.
8. **Live Event Viewer**: For continuous monitoring and updates, use the Live Event Viewer feature which displays events as they occur, often tailored to specific security alerts defined by an event code (e.g., "Security:529").
9. **Data Monitor Creation**: Set up a custom data monitor to track recent logon failure attempts specifically for Windows users. This involves setting criteria like "/Authentication/Verify" under the categoryBehavior field, which is indicative of authentication processes that could be linked back to failed login attempts.
This process demonstrates how to systematically analyze and filter through large datasets using advanced search tools, with an emphasis on user-specific behaviors and security events related to product failures across various platforms and technologies.
Here's a summarized version of your detailed description:
1. **Search Query Construction**: You constructed a search query that involves authentication failures involving Microsoft devices, specifically looking at events where the destination user name is not null and includes "Microsoft" in the device product details. The query was structured as follows:
```
categoryBehavior = "/Authentication/Verify" AND categoryOutcome = "/Failure" AND NOT (destinationUserName IS NULL) AND deviceProduct CONTAINS "Microsoft"
```
2. **Query Execution and Visualization**: You executed the search and visualized the top destination user names by clicking on "Top values". This automatically generated a chart based on your query.
3. **Chart Options**: You noted that you couldn't access the Field Summary option while viewing this chart, but you could choose to chart either "Values by Time" or "Top Values".
4. **Saving the Chart for Dashboard Use**:
Clicked on the "Dashboard Panel" and selected "Saved search" as "Microsoft Authentication Failures", reusing your query.
Created a new dashboard named "Microsoft Related Events".
Added both types of charts (Pie and Line) to this dashboard.
Configured the chart type to Pie and saved it.
5. **Accessing the Dashboard**:
After saving, you navigated to "Dashboards" and selected your newly created "Microsoft Related Events" dashboard to view it.
6. **Building on the System-Generated Dashboard**: You clicked on "View on Search Page" which redirected you to the Analyze tab where you adjusted a similar query:
```
(/Authentication/Verify AND /Failure AND deviceProduct CONTAINS "Microsoft") | where deviceEventClassId is not null | top deviceEventClassId
```
This summary captures the main steps and actions taken in your detailed workflow, focusing on setting up and managing searches and visualizations related to Microsoft-related authentication failures.
This document outlines how to navigate and customize a report related to Microsoft login errors. The process begins with opening "Reports" from the main menu, then selecting "Report Explorer" under "Navigation." From there, choose "Operating System" and select "OS-Login Errors by User." By clicking on "Quick Run with default options," you can generate a basic report.
To customize this report, copy it into the "Default Reports" group, save it as a new report named "OS-Login Failure by User," then adjust the query to change the object from OS-Login Errors by User to OS-Login Failures by User. This allows for customization and modification of the original report.
The text describes the process of creating and saving a new query in a report tool, specifically for monitoring operating system login failures by user. Here's a summary of the steps involved:
1. **Initial Setup**: Uncheck "Load in New Window" and click on "EDIT" to modify the query settings.
2. **Change Query Settings**: Update the WHERE clause to filter events related to warnings, specifically targeting categories like '/Operating System', '/Authentication/Verify', '/Informational/Warning', and '/Failure'. Additionally, add a condition for devices by 'Microsoft'.
3. **Save the Query**: Save the query with the name "OS-Login Failures by User" and place it in the "Default Reports" query group.
4. **Run the Report**:
Select all fields from the new query.
Click on "SAVE", then "OK".
Go to "Preview" and click "Run Now" to execute the report.
5. **Report Execution**: Navigate through the reports using the provided hierarchy (Reports > Report Explorer > Operating System > OS-Login Failures by User) and run it with default options for quick execution.
The document also briefly explains the role of pipeline operators in refining searches, such as using keys to identify specific data points from raw events and applying conditions through various operators like Regex for pattern matching or Replace for text alteration. These operators are crucial for tailoring search queries to specific needs within larger datasets.
The summarized content describes a system or software tool used for analyzing network traffic data, specifically focusing on Netflow and Blue Coat events. The tool allows users to perform various types of analyses by using different operators and commands. Here are some key points from the text:
1. **Rex Operator**: This operator is used to extract values based on a specified regular expression. It can be applied to raw event data to derive specific information such as terms extracted from Google search URLs after "q=" in a query string format, which could include details about network traffic or other relevant data captured by the tool.
2. **Transaction Grouping**: This feature groups events that have identical values in specified fields (like host and portNum). If two events share the same host and portNum, they are grouped into a transaction. The transactions are then sorted in ascending order based on their IDs, and duration is calculated as the time difference between the first and last event of the transaction.
3. **Event Count**: Displays the number of events within each transaction.
4. **Where Operator**: Allows users to filter events that match criteria specified in a "where" expression. This functionality extends to using field-based operators on raw events, which can be user-defined fields extracted from raw data using pipeline operators like Rex.
5. **Examples of Searches**:
For counting the occurrences of different destination ports in Netflow traffic: `netflow | cef dpt | chart _count by dpt | sort - _count`. Change the chart type to "Line".
To calculate average byte counts (in and out) for Netflow traffic every 30 seconds: `Netflow | cef bytesIn bytesOut | chart avg(bytesIn), avg(bytesOut) span=30s`.
For identifying the source addresses responsible for firewall traffic and calculating total byte counts: `categoryDeviceGroup = "/Firewall" AND categoryBehavior = "/Access" and bytesIn IS NOT NULL | EVAL total_bytes = bytesIn + bytesOut | chart sum(total_bytes) as bytes by sourceAddress | sort - bytes`.
6. **Searching Blue Coat Events**: The example demonstrates how to write a search string that targets Blue Coat events using the pipe operator and rex command. This specific example extracts information after "q=" in a Google search URL query, indicating it could be used for analyzing traffic or other data related to queries performed through Google from devices associated with Blue Coat.
This system provides powerful capabilities for network administrators and analysts to extract actionable insights from complex network traffic data efficiently.
This summary provides a quick overview of how to query data using various filters in an unspecified logging or monitoring system. Here's the breakdown of each query described:
1. **Top Device Vendors**: Lists the top device vendors based on the available data.
2. **Top Device Products**: Lists the top device products as reported by the devices.
3. **Versions of Connectors Reporting into Logger**: Shows which versions of connectors are reporting information into the logger from the devices.
4. **TippingPoint Events per Hour**: Provides a count of TippingPoint events occurring every hour, aggregated across all instances.
5. **What’s Coming into Logger?**: Lists the top names of data sources that are being logged or monitored in the system.
6. **Failed Logins by User**: Identifies users who have failed login attempts using specific criteria related to authentication failures and non-null usernames.
7. **Top NetFlow Destination Ports**: Displays the most common destination ports used for Cisco NetFlow devices, where the port number is greater than 0.
8. **Products with Changes Recently**: Lists products that have had modifications made recently based on specific behavior patterns in the system.
9. **Example of Regex Query**: Demonstrates a query using regular expressions to filter data related to Zara from a broader dataset involving CEF entries and devices like Unix.
10. **Top 20 Products by Event Count (Non-aggregated)**: Lists the top 20 device products based on event count without considering aggregation or grouping.
11. **Top 20 Products by Event Count, Aggregation Used**: Similar to above but shows results after aggregating events per product for a more detailed analysis.
12. **Events by Each Source (Sorted)**: Sorts the total number of events from each source in descending order based on their occurrence.
13. **Blue Coat Bytes In and Out**: Queries related to data transfer volumes (BytesIn and BytesOut) for devices belonging to Blue Coat, specifically excluding entries that contain "wind" in the destination hostname.
Each query is designed to extract specific insights from a large dataset, using filters tailored to different aspects of network activity or device configurations.
The provided commands are used for analyzing network traffic data from a Blue Coat device. Here's a summary of each command:
1. **Summarize Network Traffic by Source Address:**
Command: `owsupdate | chart sum(bytesIn) as TTLBytesIn, sum(bytesOut) by sourceAddress | sort – TTLBytesIn`
Description: This command aggregates the total number of bytes received (bytesIn) and sent (bytesOut) from each unique source address. It then sorts the results by the total bytes in descending order.
2. **Summarize Network Traffic Excluding Windows Updates:**
Command: `deviceVendor="Blue Coat" and destinationHostName is not null AND NOT destinationHostName CONTAINS "windowsupdate" | chart sum(bytesIn) as TTLBytesIn, sum(bytesOut) by sourceAddress | sort – TTLBytesIn`
Description: This command filters out traffic to the Windows Update host (indicated by `destinationHostName`), then aggregates and sorts the network traffic data similarly to the first command.
3. **Analyze Successful Transactions:**
Command: `Transaction categoryBehavior = "/Authentication/Verify" AND categoryOutcome CONTAINS "/Success" AND destinationUserName IS NOT NULL | transaction deviceProduct, destinationUserName maxspan= 2h`
Description: This command identifies successful authentication transactions where the destination user name is not null. It then summarizes these transactions by product and username over a maximum span of two hours.
4. **De-duplicate Transactions and Sort:**
Command: `Transaction categoryBehavior = "/Authentication/Verify" AND categoryOutcome CONTAINS "/Success" AND destinationUserName IS NOT NULL | transaction deviceProduct, destinationUserName maxspan= 2h | dedup deviceProduct, destinationUserName | sort deviceProduct destinationUserName`
Description: This command performs the same transaction analysis as the previous one but first removes duplicate entries to ensure each unique product and username pair is accounted for. Finally, it sorts the results by product and username.
These commands help in monitoring network traffic, identifying specific hosts, analyzing authentication transactions, and ensuring data integrity across various parameters.
Comments