--- version: "7.14.0" language: "en" --- # LogRhythm UEBA (formerly CloudAI) ## Documentation ### [LogRhythm UEBA](https://docs.logrhythm.com/ueba/docs/logrhythm-ueba.md) ### [User and Entity Behavior Analytics Module](https://docs.logrhythm.com/ueba/docs/user-and-entity-behavior-analytics-module.md) * ### [UEBA Lab](https://docs.logrhythm.com/ueba/docs/ueba-lab.md) * ### [Download PDFs](https://docs.logrhythm.com/ueba/docs/download-pdfs.md) --- version: "7.14.0" language: "en" --- # Anomaly Event Timeline The timeline provides hour-by-hour information about the anomalies observed for the selected user. An Anomaly Score (1-100) displays on each Event Card in the Threat Event Timeline. You have the following options: * To view the event timeline for a specific day, select a day from the Scored Date list at the top of the Event Card. By default, the Latest Scored Date is selected and shows the results form the previous processing run. Select a different Scored Date to see the results of a 24-hour processing run. * To see more information about a specific event, point to the title of the Event Card (for example, Unusual Login Activity). * To search a particular event for the user, click the**Search** icon next on the Event Card. A search task displays in the taskbar indicating that the search is in progress. To view more information about the search, point to the search task. ## User Anomaly Score An Anomaly Score (1-100) displays on each Event Card in the Threat Event Timeline. The Event Card shows the total number of Threat Events that contribute to the Anomaly Score and lists each event below the Event Card. The Anomaly Score represented is composed of 24 hours of aggregated User Event Scores from each hour. Any single hour is not weighted above another. The Anomaly Score is based on how anomalous each of the last 24 hours are compared to the baseline activity. That is, anomalous activity today is considered part of your baseline activity tomorrow, and will change your score insofar that it is now part of your baseline. However, most of the baseline days do not have anomalous activity, so the baseline will not change significantly. For more detailed information on User Anomaly Scores, see Understand User Anomaly Scores. ### Behavior Models The following Behavior Models contribute to a User's Anomaly Score and Event Scores. | Behavior Model | Description | |-------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Authentication Classification | Derived from the number and type of authentication events across all impacted hosts. Behavior Model Anomaly Score is a composite of several different recognized authentication-related events, including recognition of new and unique Common Events, changes in Common Events over a given time, the number of successful and failed authentications on all impacted hosts, and the percentage of failed authentications on all impacted hosts. | | Impacted Host | Derived from data pertaining to impacted hosts during the Scored Period. Behavior Model Anomaly Score is a composite of several different recognized events occurring on impacted hosts, including authentication attempts to unfamiliar hosts, the number of connections and standard deviation of the number of connections, the total number of impacted hosts to which the user tried to connect or authenticate, and the maximum number of connections to impacted hosts. | | Login Time | Derived from authentication behavior observed in each hour of the day during the Scored Period. The model anomaly score is a composite of authentication activity at the specific hour. | | Origin Host | Derived from the data pertaining to origin hosts during the Scored Period. Behavior Model Anomaly Score is a composite of several different recognized events occurring from origin hosts, including the total number of distinct origin hosts not previously observed in the Baseline Period from which the user tried to authenticate, the total number of distinct origin hosts from which the user tried to authenticate, the total and average number of connections from all origin hosts, and the maximum number of authentication attempts from single origin hosts. | | Origin Location | Derived from data pertaining to geographic origin. Behavior Model Anomaly Score is a composite of several different recognized events relating to the geographic location of origin hosts, including the average distance and standard deviation distance (in miles) between observed origin locations, the number of geographic locations and unique geographic origin locations not previously observed in the Baseline Period to which the user attempted to authenticate, and the maximum and total distance (in miles) between observed geographic locations. | | Peer Group | Indicates a deviation in a user's activity when compared to the activity of their peer group. This includes unusual authentication classification, unusual origin location, no peer activity, unusual origin host activity, unusual impacted host activity, and unusual login time activity. | ### Behavior Features For each Behavior Model there are Behavior Features that contribute to a user's Anomaly Score. Point to the feature title in the Threat Event Timeline for a detailed description of the observed Behavior Feature. The associated score indicates how much the event differed from the expected behavior. ## Event Scores CloudAI evaluates features as part of its behavior models. Each behavior model has multiple features that are evaluated on a per hour basis for each user. This calculation is represented by Event Scores. The Event Score Cards only display Event Scores exceeding a dynamic threshold. This is intended to be dynamic and improve over time. The expected value on the event card includes a deviation in these models, and a higher Event Score indicates an event that was more unlikely, based on the models, for the event to take place. Event Scores and User Anomaly Scores are calculated four times daily (00:00, 06:00, 12:00, and 18:00 UTC). The User Anomaly Score is calculated as a single score for the 24-hour period, while Event Scores are calculated for each hour. The Event Scores and User Anomaly Score are written to the anomaly.log file on the SIEM. Within an hour, all events that fall under the same Behavior Model must receive the same score. Event Scores from different Behavior Models are independent from one another and likely differ from each other even for the same expected and observed counts. --- version: "7.14.0" language: "en" --- # CloudAI Environment Metrics From the CloudAI tab in the WebConsole you can check the CloudAI Environment Metric as follow: ![image2022-5-10_15-36-8.png](https://docs.logrhythm.com/__attachments/a_9ffc43ae4cc5b2dcc0d046a44dd42e793222d813a24baf615b3b523af614814b/image2022-5-10_15-36-8.png?cb=b668ef4f9c6a731caa227567f36812de) --- version: "7.14.0" language: "en" --- # CloudAI Web Console UI Overview CloudAI is now named LogRhythm UEBA. However, both names are referenced in our documentation. While the product name is now LogRhythm UEBA, the user interface (UI) continues to reference CloudAI. The CloudAI Overview Page includes processing statistics, the user distribution graph, the Top Anomalous Users widget, and the Top Anomalous Events widget. The processing statistics are always shown at the top of the page. To add a widget to the page, click the **Add Widget** icon on the top navigation bar, point to the widget in the list, and then click and drag the widget to a location on the dashboard. For more information on creating and customizing dashboards, see the [Dashboards](https://docs.logrhythm.com/docs/enterprise/web-console-user-guide/dashboards) topic in the Web Console User Guide. To move and resize the user distribution graph, the Top Anomalous Users widget, and the Top Anomalous Events widget: * To move the widget to a different location on the page, point to the widget until you see the move cursor, and then click and drag the widget to a new location. * To change the size of the widget, point to the lower-right corner of the widget until you see the resize cursor, and then click and drag to resize the widget. ## Processing Statistics The top of the CloudAI Overview page shows CloudAI processing statistics. The Data Stream field shows the data processing rate. The Users, Observations, and Threat Events fields are anomaly detection results that show the number of users analyzed in the current Scored Period, and the resulting number of unique observations and threat events. Additionally, the processing statistics contain CloudAI Lab. For more information, see [CloudAI Lab](https://docs.logrhythm.com/docs/ueba/cloudai-lab). CloudAI Lab is subject to frequent changes to provide the latest features and analytics. For more information on the latest updates to CloudAI Lab, see the CloudAI Lab page on the [LogRhythm Community](https://community.logrhythm.com/). ## User Distribution Graph A tally of the User Anomaly Scores for all network users over the Scored Period, divided into quartiles. You have the following options: * To highlight a representation of users in one quartile of the graph and gray out the others, point to a quartile at the top of the graph. * To show the number of users with that Anomaly Score during the Scored Period, point to any bar on the graph. * To copy the widget to another dashboard, or delete the widget, point to the widget and click the **Settings** icon. * To show users within a specific Anomaly Score range, click and drag over a range on the graph. The graph opens on the CloudAI Analyze page with a table of users within the selected range. You have the following options: * To view the Threat Event Timeline for a particular user, click the event card for the user in the list. * To run an investigation on a specific user, click the **Search** icon next to the user in the list. * To add a user to a list, click the **Lists** icon. Select Ignore for 24 hours to add the user to the ignore list. This list is used to hide users with high anomaly scores that are expected (for example, when a new account is created). To add to any other list, select the list from the drop down. * To add a user to a case or create a new case with the user, click the **Cases** icon and select an option. ## Top Anomalous Users Widget The users with the highest User Anomaly Scores in the Scored Period are listed in order from highest to lowest from the top of the vertical axis down. You have the following options: * To view the Threat Event Timeline for a particular user, click the event card for the user in the list. * To search for a user in the list, type a user name in the Search usernames box. * To run an investigation on a specific user, click the **Search** icon next to the user in the list. * To add a user to a list, click the **Lists** icon. Select Ignore for 24 hours to add the user to the ignore list. This list is used to hide users with high anomaly scores that are expected (for example, when a new account is created). To add to any other list, select the list from the menu. * To add a user to a case or create a new case with the user, click the **Cases** icon and select an option. * To see the filters applied to the widget, point to the **filter** icon at the top of the widget. For more information, see [Configure the Top Anomalous Users Widget](https://docs.logrhythm.com/ueba/docs/configure-the-top-anomalous-users-widget.md). ## Top Anomalous Events Widget The events with the highest anomalous scores in the Scored Period are listed in order from highest to lowest from the top of the vertical axis down. The widget displays the event score, time of the event, name of the event, and user associated with the event. You have the following options: * To view the Threat Event Timeline for a particular user, click the event card for the user in the list. * To run an investigation on a specific user, click the **Search** icon next to the user in the list. The search is based on the behavior and hour in the event for the specific user. * To add a user to a list, click the **Lists** icon. Select Ignore for 24 hours to add the user to the ignore list. This list is used to hide users with high anomaly scores that are expected (for example, when a new account is created). To add to any other list, select the list from the menu. * To filter the events in the list, type an event type in the Filter Events box at the top of the list. Alternatively, click the event type icon on the event card. * To view events for users in a particular list, select a list from the **Select an identity list** menu. * To see the filters applied to the widget, point to the **filter** icon at the top of the widget. * To view more events, scroll or use the scroll bar within the widget. For more information, see [Configure the Top Anomalous Events Widget](https://docs.logrhythm.com/ueba/docs/configure-the-top-anomalous-events-widget.md). --- version: "7.14.0" language: "en" --- # Configure LogRhythm CloudAI as a LogSource CloudAI is now named LogRhythm UEBA. However, both names are referenced in our documentation. While the product name is now LogRhythm UEBA, the user interface (UI) continues to reference CloudAI. To make the CloudAI output logs visible in the LogRhythm SIEM, the LogRhythm Client Console needs to be configured to accept CloudAI log sources. If you are using multiple DX in your SIEM environment make sure you set up LogRhythm CloudAI as a LogSource (LogSourceTypeName = "LogRhythm CloudAI") in all of your DX otherwise you may miss some LogRhythm UEBA output logs. To configure a CloudAI log source: 1. Log in to the LogRhythm Client Console as a Global Administrator. 2. On the main toolbar, click **Deployment Manager**. 3. Click the **System Monitors** tab. 4. Double-click an Agent that can access the Data Indexer log files, such as an Agent on the Data Indexer. The System Monitor Agent Properties dialog box appears. 5. Right-click the grid on the bottom of the dialog box, and then click **New** . The Log Message Source Properties dialog box appears. 6. Complete the following tabs: * Basic Configuration * In the Log Message Source Type Field, add **LogRhythm CloudAI**. * In the Log Message Processing Engine (MPE) Policy Field, select **LogRhythm Default**. * Additional Settings * Select the **Start collection from the beginning of the log** check box. * Flat File Settings * In the File Path field, type one of the following, depending on your operating system: * *Windows* . **C:\\Program Files\\LogRhythm\\Data Indexer\\logs\\anomaly.log** * *Linux* . **/var/log/persistent/anomaly.log** * In the Date Parsing Format field, select **LR UEBA EventTime**. 7. To save the new log source, click **OK**. For more information on configuring new log sources, see [Log Sources](https://docs.logrhythm.com/docs/enterprise/client-console-administrator-guide/log-sources). --- version: "7.14.0" language: "en" --- # Configure Monitored Identities List TrueIdentities need to be maintained periodically as new users are added, removed, or updated. You must configure the "CloudAI: Monitored Identities list" to include all identities you want analyzed by LogRyhthm UEBA. The Monitored Identities List should have less than or equal to the number of identities to be analyzed that were purchased. If the list exceeds the licensed limit, the entire list will be rejected. This step is required following upgrade to 7.3.2. ## Configure the Monitored Identities List (On-premises Installations) For on-premises installations, configure the Monitored Identities List via the LogRhythm Web Console. 1. Log in to the LogRhythm Web Console. 2. On the right side of the top navigation bar, click the **Administration** icon, and then click **Lists** . The Lists grid appears. 3. Search for and select the **CloudAI: Monitored Identities** list from the Lists grid. The Inspector panel opens on the right side of the page. 4. Scroll to the bottom of the Inspector panel and click **Contents** . The Contents section expands. 5. Enter new list entries manually, or browse the tabs of known values and select which items you want to add to the list. You can use the Control or Shift key to select multiple entries at once. For more information about item types available for each list type, see [Lists in the Client Console](https://docs.logrhythm.com/docs/enterprise/client-console-analyst-guide/lists-in-the-client-console). In LogRhythm Enterprise 7.3.2, Entity Segregation does not apply to Identity lists. When adding or modifying Identity list items, any Identity can be selected, regardless of the Entity to which it is associated. Contact your [Customer Relationship Manager](https://docs.logrhythm.com/docs/enterprise/find-more-information/customer-support-guide) if you use Entity Segregation and need further assistance. 6. Click **Add** to add the item. The Add button names vary depending on the type of entry being added. For more information, see the [Add List Items in the Web Console](https://docs.logrhythm.com/docs/enterprise/web-console-user-guide/lists-in-web-console/add-list-items-in-the-web-console) topic of the Web Console User Guide. ## Configure the Monitored Identities List (LogRhythm Cloud) In LogRhythm Cloud, configure the Monitored Identities List via the Client Console. ### Access the Client Console The LogRhythm Client Console is delivered via a solution called Cameyo. This solution provides an RDP-like experience through an HTTPS-secured HTML5 web app. Cameyo can be accessed at this URL: [https://logrhythm.cameyo.com](https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Flogrhythm.cameyo.com%2F__%3B!!JDMJG6caUXP-JmY2!XK_W4bLzZCa6Az9Vz4eBeqF1GhU92aJWbcQe4McRjYKYX3-yJWNNQpUAzuKF%24&data=04%7C01%7Cmelissa.ruzzi%40logrhythm.com%7C9b6589b566d54206205c08d9fad0d6e1%7C643bc53fd0ae4e65af7b2e3a0db367e1%7C1%7C0%7C637816597205752968%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SVjDgBbJE%2B9bV3GZeVAsR7HUXl4G2fmQP7WnQVIjAIs%3D&reserved=0) Users log in to Cameyo using either an O365 or Google account. Local accounts such as AD or on-prem Exchange cannot be used for Cameyo authentication. The LR Cloud team must grant permissions to the O365 or Google account to enable access the customer's corresponding environment. After the LR Cloud team authenticates the account, the user can log in to Cameyo, To access the Client Console: 1. Log in to Cameyo using your authenticated O365 or Google account. A tile appears. 2. Click the tile. The Client Console log in screen appears. 3. Enter your Client Console credentials. 4. On the main toolbar, click **List Manager** . The Lists grid appears. 5. Search for theCloudAI: Monitored Identities list from the Lists grid. 6. Right-click the **CloudAI: Monitored Identities** row, and click **Properties** . The List Properties dialog box appears. 7. Click the **List Items** tab and add or remove items as needed. 8. Click **OK**. --- version: "7.14.0" language: "en" --- # Configure the Top Anomalous Events Widget To configure the Top Anomalous Events widget: 1. On the top navigation bar, click **CloudAI**. 2. Point to the widget and then click the **Settings** icon. The Settings window appears. 3. Complete the following: * *Order* . To change the order of the list to descending or ascending, click **Top** or **Bottom**, respectively. * *Identity Lists*. To display users from a specific Identity list, select a list from the Identity list menu. A preview of the list appears. * *Title*. To use a custom title for the widget, select Custom and type a title. * *Delete Widget* . To delete the widget from the CloudAI Overview page, click **Delete Widget**. --- version: "7.14.0" language: "en" --- # Configure the Top Anomalous Users Widget To configure the Top Anomalous Users widget: 1. On the top navigation bar, click **CloudAI**. 2. Point to the widget and then click the **Settings** icon. The Settings window appears. 3. Complete the following: * *Order* . To change the order of the list to descending or ascending, click **Top** or **Bottom**, respectively. * *Identity Lists*. To display users from a specific Identity list, select a list from the Identity lists. A preview of the list appears. * *Widget Filter* . To filter the list of users using Lucene syntax, select **None** , **Common** , or **Custom**, and then select or type the required information. * *Title*. To use a custom title for the widget, select Custom and type a title. * *Delete Widget* . To delete the widget from the CloudAI Overview page, click **Delete Widget**. --- version: "7.14.0" language: "en" --- # Download PDFs This section provides downloadable PDFs of UEBA and CloudAI documentation. ## LogRhythm UEBA (formerly CloudAI) [LogRhythm UEBA (formerly CloudAI) User Guide](https://resources.logrhythm.com/7.14.0/LogRhythm-UEBA-and-CloudAI-User-Guide-7.14.0-RevA.pdf) [LogRhythm UEBA (formerly CloudAI) Offboarding Guide](https://resources.logrhythm.com/docs/LogRhythm-UEBA-(formerly-CloudAI)-Offboarding-Guide-RevA.pdf) [UEBA Lab (formerly Cloud AI Lab)](https://resources.logrhythm.com/7.13.0/LogRhythm-UEBA-Lab-RevA.pdf) ### UEBA [User and Entity Behavior Analytics (UEBA) Module User Guide](https://resources.logrhythm.com/docs/LogRhythm-User-and-Entity-Behavior-Analytics-Module-User-Guide-RevA.pdf) --- version: "7.14.0" language: "en" --- # Enable the Knowledge Base Module The LogRhythm Knowledge Base UEBA module contains rules that make use of LogRhythm UEBA outputs. To take full advantage of the use cases, the module must be enabled. To enable the module: 1. Log in to the LogRhythm Client Console as a Global Administrator. 2. On the main toolbar, click**Tools** , click **Knowledge** , and then click**Knowledge Base Manager** . The Knowledge Base Manager appears. 3. In the Knowledge Base Modules grid, select the **Action** check box for the User and Entity Behavior Analytics module. 4. Right-click the selected module, click **Actions** , and then click **Enable Module**. 5. To close the Knowledge Base Manager, click **OK**. 6. On the main toolbar, click **Deployment Manager**. 7. Click the **AI Engine** tab. 8. Select the **Action** check boxes for the CloudAI rules. 9. Right-click the selection, click **Actions** , and then click **Enable**. 10. At the bottom of the window, click the **Workloads** tab. 11. In the Workloads grid, select the default Workload. 12. In the Rule Sets grid, select the **Action** check box of the Rule Set that contains the UEBA rules. 13. Right-click the selection, click **Actions** , and then click **Include in Workload** . The Include Rule Sets message box appears. 14. To assign the Rules to the Workload, click **OK** . The Rules Included confirmation message appears. 15. Click **OK**. --- version: "7.14.0" language: "en" --- # Getting Started in LogRhythm UEBA CloudAI is now named LogRhythm UEBA. However, both names are referenced in our documentation. While the product name is now LogRhythm UEBA, the user interface (UI) continues to reference CloudAI. You must integrate LogRhythm UEBA (formerly CloudAI) with your LogRhythm deployment before you can access data. For technical assistance, contact [LogRhythm Customer Support](https://docs.logrhythm.com/docs/enterprise/find-more-information/customer-support-guide). ## Set Up LogRhythm UEBA on Your LogRhythm Deployment The steps required to set up and configure LogRhythm UEBA in your LogRhythm deployment are described in the following sections. Within forty-eight hours of configuring LogRhythm UEBA, the Web Console widgets start to retrieve anomaly scores. ## Request Access Access to LogRhythm UEBA (CloudAI) is currently only available when you have a valid subscription. Contact your [Customer Relationship Manager](https://docs.logrhythm.com/docs/enterprise/find-more-information/customer-support-guide) to learn more and sign up for this service. ## Configure TrueIdentities TrueIdentities must be configured for LogRhythm UEBA (CloudAI) to monitor. For more information, see the [LogRhythm Software Installation Guide](https://docs.logrhythm.com/docs/deploy) and the [Client Console Administrator Guide](https://docs.logrhythm.com/docs/enterprise/client-console-administrator-guide). This step is required following upgrade to 7.4.0. ## Configure the Monitored Identities List LogRhythm UEBA uses the "CloudAI: Monitored Identities" list in your LogRhythm SIEM to know which identities it should analyze. Make sure this list includes all identities you want analyzed. The Monitored Identities List should have less than or equal to the number of identities to be analyzed that were purchased. If the list exceeds the licensed limit, the entire list will be rejected. This step is required following upgrade to 7.3.2. --- version: "7.14.0" language: "en" --- # Grant Access to LogRhythm UEBA CloudAI is now named LogRhythm UEBA. However, both names are referenced in our documentation. While the product name is now LogRhythm UEBA, the user interface (UI) continues to reference CloudAI. Users can only access LogRhythm UEBA (CloudAI) data through the Web Console if their user profile is explicitly granted permission to do so. To grant access to certain user profiles: 1. Log in to the LogRhythm Client Console as a Global Administrator. 2. On the main toolbar, click **Deployment Manager**. 3. On the Tools menu, click **Administration** , and then click **User Profile Manager** . The User Profile Manager window appears. 4. Select a user profile, right-click the selection, and then click **Properties**. 5. On the General tab, in the Allow section, select **CloudAI Access**. 6. Click **OK**. --- version: "7.14.0" language: "en" --- # Install and Configure LogRhythm UEBA Components CloudAI is now named LogRhythm UEBA. However, both names are referenced in our documentation. While the product name is now LogRhythm UEBA, the user interface (UI) continues to reference CloudAI. The LogRhythm UEBA (formerly CloudAI) configuration steps 6-10 below changed on LogRhythm version 7.6.0. If you have an existing CloudAI installation and are upgrading LogRhythm 7.5.1 (or earlier) to LogRhythm 7.6.0 (or newer), you must repeat steps 6-10 below on your Platform Manager (or XM) for CloudAI to function properly. After you establish your UEBA subscription, you will receive a certify-\-windows.zip installer. All traffic to LogRhythm UEBA is initiated from the SIEM and goes over TCP/443, using HTTP over TLS. Watchtower and Transporter on the Data Indexer communicate with the appropriate url depending on the GCP location, and the Web Console API on the PM communicates with ui.analytics.logrhythm.com. To complete the installation and configuration of CloudAI: 1. Extract the contents of the .zip file to an accessible location on your machine. To do this, enter the password provided. 2. Run the Certify installer in the .zip file on your Platform Manager: * In the extracted folder, double-click the**Certify.msi** file to run it. * If the installer runs successfully, it creates a folder to store the certificates. The default location for the certificates is C:\\Program Files\\LogRhythm\\Data Indexer\\Certify. Certify does not need to be run on any Data Indexer in the deployment. You only need to install Certify on the Platform Manager. 3. Open a command prompt as an administrator and go to C:\\Program Files\\LogRhythm\\LogRhythm Authentication Services\\LogRhythm Authentication API\\updateAICloudCertificate. 4. Run **configure.bat**, and in the window that opens, provide the following information: | Field | Description | |-----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Username | Your LogRhythm Web Console user name for an account with administrative privileges to update the EMDB. | | Password | The corresponding password for the user name. | | Company name | Your company name as it is defined in your CloudAI account. This can also be found in the name of the certify zip file: certify-\-windows.zip | | Public key file name | C:\\Program Files\\LogRhythm\\Data Indexer\\Certify\\TAC.pub (This is the absolute path to the TAC.pub file installed by Certify). If the TAC.pub file is installed in the default location provided, this prompt can be left blank. | | Private key file name | C:\\Program Files\\LogRhythm\\Data Indexer\\Certify\\TAC.key (This is the absolute path to the TAC.key file installed by Certify). If the TAC.key file is installed in the default location provided, this prompt can be left blank. | The configure.bat script will display the following message when completed: `Successfully updated the application used to verify requests to the AI Cloud.` `Type any key to exit` Once completed, type any key, and the window will close and the script will exit. 5. After configure.bat has finished running, restart the **LogRhythm Authentication API** service. 6. Launch the Configuration Manager: 1. Click **Show** on the Advanced View option. 2. On the left-side navigation menu, click **CloudAI**. 3. Change the **Enable CloudAI** field to **Enabled**. 7. *(Optional)*To configure the URL the Web Console will communicate with, launch the LogRhythm Configuration Manager. 1. Click **Show** on the Advanced View option. 2. On the left-side navigation menu, click **CloudAI**. 3. Change the **CloudAI Results API URL**field to the target data center. 4. Click **Save**. Only use the URL provided for your region by customer support. You must also change the **CloudAI Ingest API URL** setting in the Configuration Manager to the endpoint provided. Do NOT change this after initial setup without contacting [LogRhythm Support](https://docs.logrhythm.com/docs/enterprise/find-more-information/customer-support-guide). 8. *(Optional)* To configure the URL the Transporter service on the Data Indexer sends log metadata to, launch the LogRhythm Configuration Manager. 1. Click **Show** on the Advanced View option. 2. On the left-side navigation menu, click **CloudAI**. 3. Change the **CloudAI Ingest API URL**field to the target data center. 4. Click **Save**. Only use the URL provided for your region by customer support. You must also change the **CloudAI Results API URL** setting in the Configuration Manager to the endpoint provided. Do NOT change this after initial setup without contacting [LogRhythm Support](https://docs.logrhythm.com/docs/enterprise/find-more-information/customer-support-guide). 9. *(Optional)* To configure a regular proxy for CloudAI Web Console configuration, launch the LogRhythm Configuration Manager. 1. Click **Show**on the Advanced View option. 2. Locate the **CloudAI Proxy URL** field in the configuration. 3. Change the **CloudAI Proxy URL** field to target your proxy. 4. Click **Save**. The Proxy Server must be a valid URL pointed to a regular proxy, not a transparent proxy. Transparent proxy paths are configured at a system level and do not require LogRhythm configuration. The Proxy Server field routes all external CloudAI traffic through the regular proxy provided. If your regular proxy uses a trusted CA certificate, you do not need to configure the proxy CA certificate in the LogRhythm Configuration Manager. If your regular proxy uses a self-signed or untrusted CA certificate, complete the following steps. 5. Locate the **CloudAI Proxy CA Certificate** field in the configuration. 6. Click **Choose File** and select the public certificate of the proxy in PEM format **OR** Change the **CloudAI Proxy CA Certificate** field to be the contents of the public certificate of the proxy in PEM format. 7. Click **Save**. 10. *(Optional)*To configure a transparent proxy for CloudAI Web Console configuration, launch the LogRhythm Configuration Manager. If your transparent proxy uses a trusted CA certificate, no configuration is needed in the LogRhythm Configuration Manager. If your transparent proxy uses a self-signed or untrusted CA certificate, complete the following steps. 1. Click **Show**on the Advanced View option. 2. Locate the **CloudAI Proxy CA Certificate** field in the configuration. 3. Click **Choose File** and select the public certificate of the proxy in PEM format **OR** Change the **CloudAI Proxy CA Certificate** field to be the contents of the public certificate of the proxy in PEM format. 4. Click **Save**. ## Verify the Configuration Verify that you are successfully sending data to CloudAI: 1. Open one of the supported browsers and go to on your Platform Manager. 2. On the Home menu at the upper-left corner of the page, click**Data Indexer**. 3. On the **Data Indexer** sub-menu, click the **CloudAI**dashboard. 4. Expand the bar at the bottom of the page labeled **CloudAI Metrics (\)**. 5. Examine the **CloudAI HTTP Responses** graph. Make sure the graph shows a line labelled **200 (OK): \**. 6. Close the browser. --- version: "7.14.0" language: "en" --- # Log Collection Best Practices Important Considerations * Ensure key log sources are collected. * Ensure all Domain Controllers (DCs) in the domain are being collected. List all DCs in the domain and ensure all are configured for security log collection. Missing DCs leaves gaps in visibility, and since you cannot predict which DC will be used for authentication for a set of hosts, or even for a region, it is variable by design in Active Directory. * Ensure appropriate Windows Audit Policies are configured for all DCs and servers. Ensure appropriate policies are configured for all DCs and servers that you are collecting from. This must include Kerberos ticket auditing for best fidelity (Audit Kerberos Authentication Service, and Audit Kerberos Service Ticket Operations). These should be configured for success and failure auditing on DCs. * Ensure Entities are fully populated. This includes ensuring Entity Networks are created and geolocation information is added, and Entity Hosts are created with DNS, IP, and geolocation information added. * Enable DNSIPTOName in MPE. DNSIPToName should be set to Resolve Internal. This depends on Reverse DNS Lookup being configured in your DNS. For more information, see the [](https://exabeam.atlassian.net/wiki/display/TLMStage/Modify+Data+Processor+Advanced+Properties) topic in the NextGen SIEM Help. ## Recommended UEBA Log Sources The following describes the log sources that provide the best fidelity data to CloudAI and AIE analytics. This may be used to prioritize which log sources to initially onboard in a deployment in order to build a baseline. ### UEBA Anomaly Detection: The following are the top log source types that provide the best fidelity data to CloudAI: * Windows Security Logs (AD) * Windows Security Logs (Local Hosts) * Any VPN Log Source * Linux Host Logs (where accounts are AD integrated or otherwise imported into TrueIdentity) * Any MFA/SSO Log Source * API - Office 365 Management Activity (if applicable) Many network device logs produce Common Events in the authentication classifications, but these are typically for authentications to the network device itself. Unless the network administration accounts are fully integrated with a centralized authentication authority, these devices are likely using a shared device account. In this case, the account will not have a TrueIdentity associated with it, and will not be passed to be analyzed. However, if the network devices are integrated to an authentication authority with individual user accounts for network device administration, and those accounts are associated with a TrueIdentity, these logs have high value to UEBA anomaly detection. ### AIE Analytics The following log sources may provide value by helping explain the reason behind what CloudAI reported, and may provide a view together with CloudAI of activity that has security relevance. * Windows Security Logs (AD) * Windows Security Logs (Local Hosts) * Windows Endpoint * Messaging (Email) * Proxy * Firewall (NGFW typically contains user information, others may not) * Any VPN Log Source * Linux Host Logs (where accounts are AD integrated or otherwise imported into TrueIdentity) * Any MFA/SSO Log Source * Network Devices (where accounts are AD integrated or otherwise imported into TrueIdentity) Log metadata **must** contain either User (Origin) IdentityorUser (Impacted) Identity in order to correlate to a CloudAI log. --- version: "7.14.0" language: "en" --- # LogRhythm UEBA CloudAI is now named LogRhythm UEBA. However, both names are referenced in our documentation. While the product name is now LogRhythm UEBA, the user interface (UI) continues to reference CloudAI. Formerly known as CloudAI, LogRhythm UEBA is a cloud-native anomaly detection engine designed to complement the existing UEBA detection capabilities available in AIEngine correlation rules. LogRhythm UEBA is LogRhythm's advanced user entity behavior analytics (UEBA) solution, and it integrates seamlessly with the LogRhythm SIEM. With the dramatic increase in the number of cyberattacks and their advancement in complexity and sophistication, it's crucial to expand detection capabilities with advanced analytics such as machine learning (ML). As reinforced by the MITRE D3FEND Framework™, anytime threat detection related to user behavior requires you to search for statistical outliners that aren't obvious, or to make a comparison against a user's baseline, you need to use advanced analytics. LogRhythm UEBA, a cloud-native add-on to the LogRhythm SIEM Platform, uses ML to detect anomalies related to potential user attacks such as insider threats, compromised accounts, administrator abuse, and misuse. Together, LogRhythm UEBA and the field-proven threat models of the LogRhythm SIEM AI Engine deliver holistic analysis and deep visibility into user activity and outliers that would otherwise go undetected. LogRhythm UEBA detects changes in user behavior that signal potential threats. Analysts can use the individual anomaly scores and a summary user score to prioritize anomalies for investigation and response. Its components are installed with the Data Indexer (DX) during a LogRhythm Enterprise installation, and LogRhythm Support performs all necessary configuration for data collection at the time you purchase a license; until then, the services installed with the DX are disabled. For more information, see the LogRhythm UEBA product data sheet: --- version: "7.14.0" language: "en" --- # LogRhythm UEBA Offboarding Guide CloudAI is now named LogRhythm UEBA. However, both names are referenced in our documentation. While the product name is now LogRhythm UEBA, the user interface (UI) continues to reference CloudAI. To disable LogRhythm UEBA (CloudAI) from your deployment, complete the following sections. ## Remove Certificate To remove the certificate: 1. From the PM/XM node, go to your System Settings, and click **Add or remove programs**. 2. Click **LogRhythm DX -- Cloud PKI Certificate** , and then click **Uninstall**. ## Disable CloudAI Configuration 1. Open the LogRhythm Configuration Manager. 2. On the left-side navigation menu, click **CloudAI**. 3. In the Enable CloudAI field, change the value to **false**. 4. Click **Submit**. ## Disable CloudAI Access To disable CloudAI access for certain user profiles: 1. Log in to the LogRhythm Client Console as a Global Administrator. 2. On the main toolbar, click **Deployment Manager**. 3. On the Tools menu, click **Administration** , and then click **User Profile Manager** . The User Profile Manager window appears. 4. Select a user profile, right-click the selection, and then click **Properties**. 5. On the General tab, in the Allow section, uncheck **CloudAI Access**. 6. Click **OK**. Access needs to be disabled for all user profiles with previous CloudAI access. For more information, see the [](https://exabeam.atlassian.net/wiki/display/TLMStage/User+Profile+Manager) topic in the NextGen SIEM Help. ## Retire Log Sources To retire CloudAI log sources: 1. Log in to the LogRhythm Client Console as a Global Administrator. 2. On the main toolbar, click **Deployment Manager**. 3. Click the **Log Sources** tab. 4. Select the Log Source Type filter, type **LogRhythm CloudAI** , and click **OK**. 5. Click **Search**. 6. Right- click and select **Check All**. 7. Under Actions, select **Retire**. ## Clear the CloudAI: Monitored Identities List 1. Click the **Administration** icon in the top-right corner, and click **Lists** . The Analyzer grid opens and Lists grid display. 2. Click the **CloudAI:Monitored Identities** list in the grid. The Inspector panel opens. 3. Scroll to the Contents section and select all Identities in the list. To select multiple Identities, press and hold the **Shift** key. 4. Click **Remove Selected**. --- version: "7.14.0" language: "en" --- # Processing, Scoring, and Time Considerations ## How Activity is Processed Event Scores and User Anomaly Scores are calculated four times daily at 00:00am, 06:00am, 12:00pm, and 06:00pm UTC. Each processing run always processes the last 6 hours of activity up and then combines the results from the previous three processing runs to calculate the overall User Anomaly Score for the last 24 hours. Note that the frequency of the processing runs is subject to change. You can tell when the last run happened from the date and time information shown on the Top Anomalous Users widget. For example, the date and time information might display the following: 07/23/2019 7:00 am - 07/24/2019 7:00 am In this example, the last processing run delivered User Anomaly Scores for each user during the timeframe from 06:00am UTC on July 23^rd^ to 06:00am UTC on July 24^th^ (an entire 24 hour period). Why does it say 7:00am in the display? The processing run always runs on UTC time, but the display shows the equivalent localized time of the appliance the Web Console is running on. In the example, the appliance happens to be in the United Kingdom during the summer, so the local time zone is UTC+1. The display shows 7:00am-7:00am for the 6am processing run, or 1:00pm-1:00pm for the 12:00 midday processing run. This always depends on when the latest processing run was performed. Consider a single processing run. The machine learning engine is comparing the last 6 hours of activity to the previous 29 days. ![time_1.png](https://docs.logrhythm.com/__attachments/a_06f0c679d9e1ab50794b7aac1b996e012cdf470c52ea8dc73ad33c2e540256f3/time_1.png?cb=676c5d58b63e289d723e0a9a8a1b8d2c) The processing run performed on June 1st at 12:00pm takes the activity for the previous 6 hours of June 1^st^ and compares that activity to the previous 29 days. In the context of the four processing runs that take place over the course of one day (starting June 1^st^ at 12:00pm), the results from that run are displayed for the next 6 hours until the next processing run. The next processing run that takes place at 18:00 on June 1^st^ processes the activity for the last 6 hours and displays those results for the next 6 hours. This process repeats continuously. ![time_2.png](https://docs.logrhythm.com/__attachments/a_102142ac43f9a6cac629d31c1ae1c4462177ecea4ccddcd266b37070ba84e3fc/time_2.png?cb=f77b4ff4ffa34b71ce5f21384b619cc5) Every 6 hours, each of the previous 6 hours are compared to the previous 29 days, and those results are visible for the following 6 hours. The processing run looks at the last 6 hours and scoring in per-hour buckets compared to the last 29 days, so new Event Scores are generated for thelast 6 hourseach run. The User Anomaly Score always represents the composite scores for the last 24 hours (that is, information is aggregated from the last ++four++ processing runs). Note that scoring is done on a per-hour basis, which is to say that each of the individual hours is scored independently against the entirety of the baseline without respect to hours of the day in the baseline. The exception to this is the time-based behavior model Login Time which compares each hour against the corresponding hour across the previous 29 days. For example, comparing 1:00pm-2:00pm to all the 1:00pm-2:00pm hour buckets for the previous 29 days. ![time_3.png](https://docs.logrhythm.com/__attachments/a_7ca66f1f117ef0cd7282a5b5898caaf875499e8a7d80d3255a943d15e9b6ee6d/time_3.png?cb=39ec22a4c0d003494613c05d7a6282c3) ## Top Anomalous Users From the Threat Event Timeline for a particular user, the overall User Anomaly Score displays at the top followed by Event Score cards. The Scored Date dropdown at the top of the User Anomaly Score card shows Latest as the selected view by default. This indicates that the displayed results are from the most recent processing run performed by CloudAI. Within the User Anomaly Score card there is a Scored Date, as well. For example, the Scored Date might display the following: 07/23/2019 7:00am This indicates the date and time of the scoring run for which activity is being scored. In this case, you might be viewing the Threat Event Timeline on the morning of July 23^rd^, and the most recently scored data is from 7:00am yesterday to 7:00am today. More simply, the Latest results always displays the results from the previous processing run (00:00am, 06:00am, 12:00pm, or 06:00pm UTC), depending on the time of day the timeline is being viewed. To select from a list of previous dates, click the **Scored Date** dropdown. ![scored_date.png](https://docs.logrhythm.com/__attachments/a_5008323c64a83d484ae23cdc7e99d41815fa2aecbdd79a5fb6daed95aecdd163/scored_date.png?cb=e7af414da6bb3b02af097e7d7faaf405) The Latest Scored Date may display the results of a processing run at 00:00am, 06:00am, 12:00pm, or 06:00pm UTC. All other Scored Dates only display a 24 hour processing run (00:00am-00:00am). The User Anomaly Score card also indicates the total number of Threat Events that are shown in the timeline in the bottom right corner. For example, the Threat Event Timeline may display 21 Threat Events. The timeline below the overall scorecard shows the Event Score cards in chronological order for the 24 hour period that was being scored. --- version: "7.14.0" language: "en" --- # TrueIdentity in LogRhythm UEBA CloudAI is now named LogRhythm UEBA. However, both names are referenced in our documentation. While the product name is now LogRhythm UEBA, the user interface (UI) continues to reference CloudAI. TrueIdentities in the Web Console represent a collection of identifiers, such as logins and email addresses, that comprise a single identity. For example, the identity Mary Moore might have two associated logins (mary.moore and mary.moore_sup) and one email address (mary.moore@recordflow.com) associated. With Identities, the following series of logs are united under the TrueIdentity Mary Moore: | First Log Date | User (Origin) | User (Origin) Identity | Classification | Common Event | Priority | |-----------------|---------------------------|------------------------|------------------------|----------------------------------|----------| | 7/22/2017 21:33 | mary.moore | Mary Moore | Access Granted | Account Added to Group | 13 | | 7/22/2017 21:07 | mary.moore_sup | Mary Moore | Access Failure | Access Object Failure | 21 | | 7/22/2017 21:05 | mary.moore | Mary Moore | Access Granted | Account Added to Group | 10 | | 7/22/2017 20:58 | mary.moore@recordflow.com | Mary Moore | Authentication Failure | User Logon Failure: Bad Password | 19 | To manage existing TrueIdentites, and create new TrueIdentities, see the [TrueIdentity Sync Client User Guide](https://docs.logrhythm.com/docs/enterprise/other-logrhythm-applications/trueidentity-sync-client-user-guide). If you have a multi-tenant environment, go to C:\\Program Files\\LogRhythm\\LogRhythm Mediator Server\\config, and set the EnableIdentityEntitySegregation parameter in the scmedsvr.ini to `True`. When configuring Active Directory (AD) synchronization, select the root entity of your Data Processor and Agent hosts that contains the logs and log sources you would like to monitor with CloudAI. For more information, see the setting information in the [Data Processor](https://docs.logrhythm.com/docs/enterprise/client-console-administrator-guide/data-processor) section of the Enterprise SIEM Help. and the [](https://exabeam.atlassian.net/wiki/display/UEBACAI) documentation. To access the TrueIdentity page, on the top navigation bar, click the **Administration** icon, and select **TrueIdentity**. --- version: "7.14.0" language: "en" --- # UEBA Deployment Guide – Configure the Module ## Configure Lists There are user-configurable lists included with the module. Use these lists to narrow the scope of AI Engine Rules and to filter events. Refer to the Description section of the List Properties to verify what should be added to the list. 1. Open the LogRhythm Console and click **List Manager**on the main toolbar. 2. Use the **Name** or **List ID**column filter to find the list you want. 3. To open the List Properties window, double-click the list. 4. Click on the **List Items** tab, and then click **Add Item**. 5. Use the **Add Item** dialog to add items to the list individually, or click **Import**to import a text file or clipboard contents. 6. Click **Apply** and then click **OK**. To identify which lists need to be configured in the environment, see the [Lists Guide](https://docs.logrhythm.com/ueba/docs/user-and-entity-behavior-analytics-lists.md). ## Configure Individual AI Engine Rules This module contains a collection of AI Engine Rules. Some rules require additional configuration to ensure that they will work properly. For configuration steps, see the [AI Engine Rules Guide](https://docs.logrhythm.com/ueba/docs/user-and-entity-behavior-analytics-ai-engine-rules.md). ## Enable AI Engine Rules 1. Open the LogRhythm Console and click **Deployment Manager** on the main toolbar. 2. Click the **AI Engine** tab. 3. Filter in the **Rule Group**column for Core Threat Detection to find AI Engine rules tied to this module. 4. Select the **Action**check box of each rule you want to configure. 5. Right-click the **AI Engine Rule Manager** , click **Actions** , click **Batch Enable Alarms** , and then click **Enable Alarms**. 6. If the **Restart** column displays "Needed" for a rule, you must restart the AI Engine service to load the new rules. Click **Restart AI Engine Servers**at the top of the window. (This action only restarts the necessary services, not the appliance itself.) You must select the AI Engine instance in the **View** field to see the **Restart**column. To view tuning and configuration notes for a rule, right-click the rule, click **Properties** , and then click the **Information**tab. Your LogRhythm Professional Services Engineer can also provide assistance with tuning AI Engine Rules for your environment. ## Enable AI Engine Rule Alarming There are several AI Engine rules which have alarms enabled by default. LogRhythm believes that these rules provide immediate insight into threats in your environment. Depending on your environment, there might be a higher quantity than normal of false positive alarms. You can disable alarms on rules that are excessively alarming. You can also tune the rule to reduce false positives. Reach out to users on the [LogRhythm Community](https://community.logrhythm.com/) to discuss your experience with rules that alarm by default as well as any AI Engine rule from LogRhythm. The following table lists the rules that are set to Alarm by default. | AIE Rule Name | AIERuleID | |-----------------------------------------------|----------------| | Progression: to Command and Control | 1285 1290 1295 | | Progression: to Exfil, Corruption, Disruption | 1288 1293 1298 | | Progression: to Initial Compromise | 1284 1289 1294 | | Progression: to Lateral Movement | 1286 1291 1296 | | Progression: to Target Attainment | 1287 1292 1297 | Even with disabled alarms, events are generated when the rule is enabled and its criteria are satisfied. These events are displayed in the Web Console Dashboard and they can be seen by running an Investigation or Tail against the Platform Manager. Before enabling Alarming, review these events and tune rules as necessary to meet an acceptable level of false positives. Refer to the [](https://exabeam.atlassian.net/wiki/display/KBStage/User+and+Entity+Behavior+Analytics+Module+User+Guide) for information about tuning individual AI Engine Rules. When finished tuning, enable alarming on the rules to bring events to the alarm layer, providing visibility to the monitoring team and allowing for notification and SmartResponse. 1. Open the LogRhythm Console and click **Deployment Manager**. 2. Click the **AI Engine** tab. 3. Filter in the **Rule Group** column for Network Threat Detection to find AI Engine rules tied to this module. The value in the Alarm Status column indicates whether alarm is enabled for a rule. 4. Select the **Action**check box of each rule you want to configure. 5. Right-click the grid, click **Actions** , click **Batch Enable Alarms,** and then click **Enable Alarms.** Alarm settings are located on the Settings tab of the Alarm Properties dialog box. ## Disable Local Windows Account Using a SmartResponse Plugin Using SmartResponse, LogRhythm can automatically disable a local Windows account after malicious activity has been identified. 1. Go to the [LogRhythm Community](http://community.logrhythm.com/). 2. On the top menu bar, click**Sharables**. 3. Click the **SmartResponses** tab, and then click the **Disable Local Windows Account** plugin and user guide. You may need to click **View more articles.** 4. Follow the instructions in the guide to import the plugin and make it available to the AI Engine rules. 5. In the LogRhythm Console, open **Deployment Manager**. 6. Then click **Tools** , **Administration** , and **Advanced Intelligence (AI) Rule Manager**. 7. Filter the Rule Group column to only contain User and Entity Behavior Analytics rules. 8. Open the first rule and click on the **Actions** tab. In the Action drop-down list, select the **Disable Local Windows Account**plugin. 9. As described in the *Disable Local Windows Account Plugin User Guide*, fill in the appropriate fields: Target Host, Target Account, Administrator Account, and Administrator Password. ## Import the Web Console Dashboard Layout Layouts currently cannot be imported as part of the KB. Instead, you must manually download and apply them. 1. Go to the [LogRhythm Community](http://community.logrhythm.com/). 2. On the top menu bar, click**Sharables**. 3. Click the **Dashboards** tab, and then click **UEBA Dashboards** **.** You may need to click **View more articles.** 4. Download the UEBA dashboards. 5. Start a supported Web browser and log in to the LogRhythm Web Console. 6. On the upper-right side of the page, click the **Dashboard Layout**icon. 7. At the bottom of the dashboard layouts list, do one of the following depending on your user permission level: * *Global Administrators* . Click either **Add Public** or **Add Private**depending on the type of view that you want to create from the import. * *All other users.* Click **Add Private**. 8. In the edit area, click **Import** . The Open dialog box appears. 9. Navigate to and select the dashboard layout file (.wdlt) that you want to import, and then click the**Open** button. The selected dashboard layout is imported into your dashboard layout menu. ## Collect SysMon Data Most of the content in this module used with a variety of network security and monitoring devices from a range of vendors. A portion of the content is written specifically to take advantage of data collected by the LogRhythm Sysmon, and without modification will not function unless LogRhythm Sysmon data is being collected by the SIEM. The table below lists objects that need the LogRhythm Sysmon. It is possible to use this content as a starting point to write a custom rule which works with data from other devices. | AIE Rule ID | AIE Rule Name | |-------------|--------------------------------------------------------| | 1305 | Compromise: Change to Host File | | 1306 | Disruption: Critical Windows Binaries Modified/Deleted | | 1302 | Compromise: Unusual Auth then Unusual Process | | 1248 | Compromise: Abnormal Process Activity | | 1258 | Corruption: Audit Disabled by Admin | --- version: "7.14.0" language: "en" --- # UEBA Deployment Guide – Import and Synchronize the Module The User and Entity Behavior Analytics Module is part of the LogRhythm Knowledge Base (KB). Updating the KB automatically creates the proper Lists and AI Engine Rules. 1. In the Client Console on the Tools menu, click**Knowledge,** and then click**Knowledge Base Manager**. To open the Knowledge Base Manager, the Deployment Manager must be closed. 2. Under Knowledge Base Modules, find the Core Threat Detection module. If the module is available, you will see User and Entity Behavior Analytics in the grid. If the module name does not appear, update the Knowledge Base by doing either of the following: * *Automatic Download* . Click **Check for Knowledge Base Updates,** and then click **Synchronize Stored Knowledge Base**. * *Manual Download* . For manual download instructions, see [](https://exabeam.atlassian.net/wiki/display/TLMStage/Import+a+Knowledge+Base)*.* 3. Locate the Enabled column in the grid. If the box is checked, the module is already enabled and available to users in the SIEM deployment. If the Enabled box is not checked, enable the module by selecting its **Action** check box, right-clicking the module name, clicking **Actions** , and then clicking **Enable Module** . A dialog box appears to enable the selected module(s). --- version: "7.14.0" language: "en" --- # UEBA Deployment Guide – Upgrade Considerations By default, updating the Knowledge Base does not update the user-customizable settings in AIE rules such as Rule Block Time Limit settings, Unique Value Rule Block occurrences and Threshold Rule Block values. The default behavior is intended to preserve any user customizations made to the AIE rules. You may want to have the latest rule settings overwrite the existing settings as part of the Knowledge Base sync. To do so you must select [enable advanced Synchronization Settings](https://exabeam.atlassian.net/wiki/display/TLMStage/Configure+Knowledge+Base+Synchronization+Settings) in the Knowledge Base Manager Synchronization Settings. Enabling this option does so for all enabled Knowledge Base modules, not just the UEBA Module. ## Configure Microsoft Windows Audit Logging Levels It is highly recommended that you follow Microsoft's guidance on "Audit Policy Recommendations." Perform a search on Microsoft's website for the latest recommendations. ## Configure Linux Audit Logging By default, most recent Linux distributions log the event of "user NOT in sudoers file" when a user tries to sudo without permission. The only requirement here is that LogRhythm collects the Auth.log via syslog, flat file or syslog file log sources. The most common collection method is to configure rsyslog to send all facilities and severities to a LogRhythm Sysmon Agent. ## Data Collection Requirements For a list of the log source types that should be collected to make effective use of each AIE rule in the UEBAM, see the [AI Engine Rule matrix](https://exabeam.atlassian.net/wiki/display/KBStage/User+and+Entity+Behavior+Analytics+%E2%80%93+AI+Engine+Rules). ## Gather the Following Information Before Deploying the Module The following information should be gathered prior to implementing the User and Entity Behavior Analytics Module. This information is needed when populating lists and configuring individual AI Engine Rules. * Critical Hosts * Critical Process Names/IDs * Organization Domain Names * Vulnerability Scanners --- version: "7.14.0" language: "en" --- # UEBA Lab CloudAI Lab is now UEBA Lab. In the Web Console at the top of the UEBA Overview page, you can view UEBA processing statistics, including users, observations, and threat events. You can also access UEBA Lab, a fully web-hosted set of UEBA features. ![image2023-6-16_13-4-43.png](https://docs.logrhythm.com/__attachments/a_87f4ace1970a33ba7099511f7a45e1b68b78fbaf23e20f8f8356f4c6b92bba58/image2023-6-16_13-4-43.png?cb=c85d26dc91a13e4cd9a63c186e433e2d) To access UEBA Lab: 1. In the upper-right corner, click **UEBA Lab** . By default, the Heatmap view appears. 2. To view Asset Details, click **Asset Details** on the main toolbar. ![image2023-6-16_13-5-36.png](https://docs.logrhythm.com/__attachments/a_0ae0cc1a6040ef424d121417cf6eca3c281cd364e4f432f5ec0b557a8783aae5/image2023-6-16_13-5-36.png?cb=57b345470188b6daa5b2f6cb3baee8c0) When you switch between Heatmap and Asset Details views, the specified timeframe persists in the new view. UEBA Lab is only available in SIEM versions 7.4.8 and later. UEBA Lab is subject to frequent changes to provide the latest features and analytics. ## UEBA Lab Features The following features are available in UEBA Lab: * Assets Details: * Identities Details: Identity job title, hosts that the identity interacted with, identity's timeline, identity's peers. * Host Details: IP and Hostname when present, Identities that interacted with the host. * Heatmap for identities UEBA labels, when available, will be present in both features. ## Identities and Hosts Interactions The asset details feature allows UEBA Lab users to search and view interactions between whitelisted assets. An asset is an entity monitored by UEBA such as a host or identity. Users can pivot between hosts and identities to further explore interactions. ### Identity View Identity View displays a list of assets that a user (identity) has interacted with during the specified time range. While in Identity View, you can do the following: * Change the time range to update the list of the identity's interactions. * Page through the list to see all the identity's interactions during the specified time range. * Click an asset on the list to view its interactions for the same time range. ### Host View Host View displays a list of assets that a host has interacted with during the specified time range. While in Host View, you can do the following: * Change the time range to update the list of the host's interactions. * Page through the list to see all the host's interactions during the specified time range. * Click an asset on the list to view its interactions for the same time range. To access the Identities and Hosts Interactions feature: 1. On the top navigation bar in the Web Console, click **UEBA**. 2. In the top-right corner of the page, click **UEBA** **Lab**. The UEBA Lab main page appears. 3. In the Explore: Identities and Hosts box, click **Try It**. The Search for Assets view appears, showing a search bar and a date range selector at the top. 4. To set the date range, enter dates in the From and To boxes in the upper-left corner. The date range defaults to the past 24 hours. 5. To search for assets, start typing your search term In the search bar. UEBA Lab auto-populates a list of asset interactions that occurred within the designated date range. When you search for an asset, the results appear in a drop-down list. The drop-down list is limited to 20 results, so you may need to refine your search term to find the asset you want. Also, if no interactions occurred within the date range you selected, the asset will not appear in the results. 6. Click on an asset in the drop-down list to view its interactions. Identities and Host labels appear when available. ![image2023-6-16_13-13-49.png](https://docs.logrhythm.com/__attachments/a_5b92e5b573fd2ddbcb5dc22823e3168ac5bdddd3628dd80e71f227146aadff08/image2023-6-16_13-13-49.png?cb=ab5115e35a4b09e6274450d52b2472bc) 7. To view interactions for another date range, enter new dates in the From and To boxes in the upper-left corner. ## Anomaly Heatmap of Identities The Anomaly Heatmap of Identities is a grid that shows anomalous behavior found for a specified identity over a 24-hour period. ![CloudAI Heatmap.png](https://docs.logrhythm.com/__attachments/a_9801dfa09bbb35fe37c3370849fbe077f9df1f2e60c04f5806672eff50cc9e43/CloudAI%20Heatmap.png?cb=17c982645085205d62a946fdcd9ada72) Each row of the grid maps an anomaly type into 1-hour blocks from the specified 24-hour window. A yellow block indicates the anomaly type occurred during that 1-hour timeframe. The brighter the yellow block, the higher the anomaly score for that hour. You can click a yellow block to view details for the anomaly type during that 1-hour block. The details appear below the heatmap grid. The following anomaly types (risk events) are mapped in the grid: | Anomaly Type | Icon | Description | |----------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------| | New Impacted Hosts | ![image2022-3-8_14-16-14.png](https://docs.logrhythm.com/__attachments/a_4bad5055b816bcc15a0fb309854a699ec4f10d650e94990e2aaafbd032592682/image2022-3-8_14-16-14.png?cb=393bbf18db02b01169713afdcb5b698a) | * Unusual number of new impacted hosts * Unusual number of new impacted hosts across monitored IDs | | New Origin Hosts | ![image2022-3-8_14-15-55.png](https://docs.logrhythm.com/__attachments/a_ce5f5f9d4cb98836df6881f025e03f703ab4e3946a178436825184e8e443f9cb/image2022-3-8_14-15-55.png?cb=2d235430b6e0dda79eefdf2e28cd70e7) | * Unusual number of new origin hosts * Unusual number of new origin hosts across monitored IDs | | New Origin Locations | ![image2022-3-8_14-16-39.png](https://docs.logrhythm.com/__attachments/a_f52530a2d640eca2c9820606bbf3b38ec609bf0c99008ee5ef2c97390941294b/image2022-3-8_14-16-39.png?cb=33940cb590793159c2afa58f49772e36) | * Unusual number of new locations * Unusual number of new locations across monitored IDs | To access the Anomaly Heatmap of Identities feature: 1. On the top navigation bar in the Web Console, click **UEBA**. 2. In the top-right corner of the page, click **UEBA Lab**. 3. In the Explore: Anomaly Heatmap of Identities box, click **Try It**. A search bar appears. 4. To search for identities, start typing your search term In the search bar. UEBA Lab auto-populates a list of identities. When you search for an identity, the results appear in a drop-down list. The drop-down list is limited to 20 results, so you may need to refine your search term to find the identity you want. 5. Click on an identity in the drop-down list to view its anomaly heatmap. The anomaly heatmap appears. A yellow block on the grid indicates anomalous behavior occurred for the corresponding anomaly type within the corresponding 1-hour time block. The brightness of the yellow block indicates the anomaly score. The brighter the yellow block, the higher the anomaly score. 6. To view the details of anomalous behavior, click a yellow block. A blue boarder appears around the yellow block, and details appear below the grid. For example, in the heatmap below, the 8pm time block in the New Origin Host row has been selected. The details about new origin hosts for the 8pm time block appear below the heatmap grid. 7. To view more information about the origin host displayed below the heatmap, click the blue link shown in the Origin Host column. If no information is available for the origin host, the value in the Origin Host column will not be blue. When you click on a linked origin host, the Search for Assets view appears. For more information, see [UEBA Lab \| id (7.14.0)UEBALab IdentitiesandHostsInteractions](https://docs.logrhythm.com/ueba/docs/ueba-lab.md#id-(7.14.0)UEBALab-IdentitiesandHostsInteractions). 8. To view the heatmap for a specific date, click the date box in the upper-right corner and select the desired date. Available dates appear on the calendar in black, and unavailable dates are greyed out. Available dates are limited to the past 30 days. By default, the heatmap shows the past 24 hours when loaded. ![image2023-6-16_13-15-50.png](https://docs.logrhythm.com/__attachments/a_e23d10b79b6e43f224db7fe5a990e43e888d66ec7958cdeadefb34e4a357f91a/image2023-6-16_13-15-50.png?cb=c712b2579ca07988cf2d9e2ee9284650) The \< 24H \> box allows you to reset the date to the past 24 hours or view the previous day or next day. ![image2023-6-16_13-16-21.png](https://docs.logrhythm.com/__attachments/a_958f16fe1a53cfec7e2ddbefc3a19f798744111ed7cf4d6d23d598ca5560daca/image2023-6-16_13-16-21.png?cb=7066518a1f8c215a1f0dc64ace05ae95) 1. To reset the heatmap to the past 24 hours, click **24H** 2. To view the heatmap for the previous day, click the **\<** arrow. 3. To view the heatmap for the next day, click the **\>** arrow. The heatmap is not designed to be used as a search engine for anomalies. Its intended use is to add more context once you discover an identity with one of the anomaly types that are mapped in the heatmap. To determine identities of interest, use dashboards, searches, or identities timelines first. ## UEBA Labels UEBA labels provide context about an asset (currently hosts or identities). They describe an asset's attribute to help you understand what the asset is and how it functions within the environment. Labels are derived from statistical and machine learning models operating on observations extracted from the security logs analyzed by UEBA over the previous 30 days. Although they are not explicitly time-based, labels persist on assets that generated relevant data within the last 30 days. Labels appear on each asset in the UEBA Lab features. For example, the following asset has two labels: Receives External Authentications and Shared Asset. ![image2021-5-31_12-16-56A.png](https://docs.logrhythm.com/__attachments/a_e200cf21e8d5edc3ccb2169f15a2630f71588547b4992c76bd41c3f269736a5f/image2021-5-31_12-16-56A.png?cb=8da1d5707d6e2166693099a5c392f339) The Labels that leverage all data are: |-------------------------------------|-----------------------------------------------------------------------| | Label | Description | | Domain Controller | Asset is a domain controller. | | Dormant Account | Identity showed no activity for at least one day in the past 30 days. | | Interactive Logons | Identity has interactively logged on. | | Local Authentications | Asset is OriginHost and/or ImpactedHost in local authentications. | | Originates External Authentications | Asset is OriginHost in external authentications. | | Originates Internal Authentications | Asset is OriginHost in internal authentications. | | Privileged Activity | Identity has logs related to account management activity. | | Receives External Authentications | Asset is ImpactedHost in external authentications. | | Receives Internal Authentications | Asset is ImpactedHost in internal authentications. | | Service Logons | Identity logged on as a service. | | Shared Asset | Asset is accessed by multiple users. | ### UEBA Labels based on NetMon data Customers who have NetMon available in their environment are able to view additional labels in UEBA Lab asset views. The NetMon data augments the UEBA analysis and provides additional context about application family types associated with asset interactions. The Labels that leverage NetMon data are: * Database server * Database client * File server * File server client For example, the following asset has two labels: Database Server and Receives Internal Authentications. ![image2020-8-20_13-42-16.png](https://docs.logrhythm.com/__attachments/a_cd322d284325272a684540c17832eb1bef6035baeb5a20a328bb09f38befc585/image2020-8-20_13-42-16.png?cb=00069d7cbbc70e8f23e317dc839640f2) --- version: "7.14.0" language: "en" --- # UEBA User Guide – AI Engine Rules ## Lateral: Multiple Account Passwords Modified by Admin ### AIE Rule ID: 1269 Attack Lifecycle: Lateral Movement ### Rule Description: An observed login by a user in the privileged user list followed by the change of two or more other account passwords. **Common Event:** AIE: Lateral: Multiple Account Passwords Modified by Admin **Classification:** Security : Suspicious **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 1 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Decide the Origin User that changed the account passwords and investigate if this action was known or unknown. If unknown, you may want to isolate the Origin Host where the account passwords changed from until an investigation can decide if a compromise has occurred. Use Case: Administrator changes passwords on multiple accounts to either use as future backdoors or to prevent users from logging in. Configuration: 1. Populate the "Privileged Users" List. a. Recommended that you review this list for accuracy at least quarterly. ## Attainment: Abnormal File Access ### AIE Rule ID: 1245 Attack Lifecycle: Target Attainment ### Rule Description: First tracks which files users generally accesses over a learning period. Afterward, triggers if a user begins accessing different files. **Common Event:** AIE: Attainment: Abnormal File Access **Classification:** Security : Attack **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** High **False Positive Probability:** 7 **Log Sources (minimum)** LogRhythm Sysmon **Log Sources (recommended)** Other File Integrity Monitoring **AIE Rule Additional Details** Action: Decide if the file access is known or unknown. If unknown, you may want to isolate the Origin Host until an investigation can decide if compromise is likely. Use Case: A user's credentials are compromised. The attacker is using that account to enumerate a shared drive's files. Configuration: LogRhythm file integrity monitoring is enabled. ## Lateral: Auth After Dispersed Failed Auths ### AIE Rule ID: 1263 Attack Lifecycle: Lateral Movement ### Rule Description: Within a short period of time, a single account unsuccessfully attempts to authenticate to multiple hosts from an external source. **Common Event:** AIE: Lateral: Auth After Dispersed Failed Auths **Classification:** Security : Compromise **Suppression Multiple:** 12 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 4 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Verify the source of the attempts and if the authentication of the user account has attempted logins from the source previously. If found that the credentials have been used previously, this could indicate that the account is shared across multiple known systems. Shared accounts should be discouraged, and you should work with the account owner in setting up individual access. If the authentication is newly attempted, you may want to disable the account until an investigation can conclude if the account was compromised. Use Case: A malicious individual finds a "sticky note" with a user name and password. The attacker then attempts to use these credentials on several different hosts, followed by a successful authentication. ## Lateral: Brute Force Internal Auth Failure ### AIE Rule ID: 1264 Attack Lifecycle: Lateral Movement ### Rule Description: Multiple failed authentication attempts from the same internal origin host to the same impacted host, without seeing an authentication success. **Common Event:** AIE: Lateral: Brute Force Internal Auth Failure **Classification:** Security : Reconnaissance **Suppression Multiple:** 12 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 5 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: You may want to isolate the Origin Host until an investigation has been performed to determine if a compromise has occurred. Additionally, you may want to disable the account and or change the password. Use Case: An attacker knows a login id to a specific host and repeatedly attempts to authenticate using various passwords (either manually or with an automated tool), and no successful authentication is observed. ## Lateral: External Attack then Account Creation ### AIE Rule ID: 1265 Attack Lifecycle: Lateral Movement ### Rule Description: Attack or compromise event from an external source followed by an account creation on the same host. **Common Event:** AIE: Lateral: External Attack then Account Creatio **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 1 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: The cost and recovery time of a compromise grows exponentially with each stage of the attack cycle, so it is imperative to stop the attack as early as possible. These rules indicate that the attacker has moved past the initial stages and is consolidating their beachhead. After the attack is stopped, it is very important to do a full sweep of the network for other signs of continued infection. Use Case: A savvy hacker successfully attacked a machine to gain access. Once in the exploited machine the hacker now created an account to use for future use and exploitation. ## Lateral: Failed Auths then Success ### AIE Rule ID: 1266 Attack Lifecycle: Lateral Movement ### Rule Description: Multiple internal unique login attempts are seen on the same impacted host within a short period of time, followed by a successful authentication. **Common Event:** AIE: Lateral: Failed Auths then Success **Classification:** Security : Compromise **Suppression Multiple:** 30 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 3 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Determine if the Origin Host is known or unknown. If unknown, you may want to isolate the system until an investigation can determine if a compromise occurred. You may also want to determine the accounts being used and if they are active in your company. For active accounts, you may want to change account names if they are found to be "Generic" and or perform password resets. Use Case: A malicious individual has a list of account names and is attempting to authenticate with one of these accounts on a single machine, followed by a successful authentication on the same machine. Configuration: Depending on the environment the amount of unique values may need to be increased for Rule Block 1. An authentication failure log is created by each domain controller in your environment. ## Compromise: Account Added to Admin Group ### AIE Rule ID: 1261 Attack Lifecycle: Initial Compromise ### Rule Description: New user added to a privileged user group. **Common Event:** AIE: Compromise: Account Added to Admin Group **Classification:** Security : Compromise **Suppression Multiple:** 3600 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 2 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Decide if account being added is known or unknown. If unknown, you may want to isolate the host until an investigation can decide if a compromise is likely. You may want to add the administrative accounts that were added to a watch list of suspicious accounts to check for to find any other compromise use. Use Case: An attacker has created at least one account and added to the administrators group. Configuration: 1. Populate the "Privileged Users" List. a. Recommended that you review this list for accuracy at least quarterly. ## Lateral: Internal Recon then Account Creation ### AIE Rule ID: 1268 Attack Lifecycle: Lateral Movement ### Rule Description: Internal reconnaissance event followed by an account creation on the same target host, indicating a possible compromise. **Common Event:** AIE: Lateral: Internal Recon then Account Creation **Classification:** Security : Compromise **Suppression Multiple:** 3 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 4 **Log Sources (minimum)** Intrusion Detection System and Active Directory or LDAP **Log Sources (recommended)** Intrusion Detection System and Host Logs **AIE Rule Additional Details** Actions: Since an internal host is already compromised, follow incident response procedures. Investigate the attacking host to see if it could access any additional hosts. Investigate the created account to see what actions it could take. Use Case: An attacker scans a machine for open ports. The IDS missed the actual attack, but shortly after the scan is detected a new account is created on the target machine, indicating some sort of attempt to maintain access. ## Lateral: Abnormal Auth Behavior ### AIE Rule ID: 1260 Attack Lifecycle: Lateral Movement ### Rule Description: First tracks which hosts an account typically authenticates to. Afterwards, triggers when a new host or hosts are being accessed by the account. **Common Event:** AIE: Lateral: Abnormal Auth Behavior **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** High **False Positive Probability:** 5 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Decide if the authentication activity is known or unknown. If unknown, you may want to isolate the Origin Host until an investigation can decide if compromise is likely. You may also want to investigate the Impacted Host to decide if another compromise has occurred. If Impacted Host is found to be compromised, you may want to isolate the host until an investigation can decide the host is safe to return to the network. You may also want to disable the account being used and or change the password of the account. Use Case: An account has been compromised and is now being used to authenticate to hosts that the user normally does not authenticate to. ## Lateral: Numerous and Dispersed Internal Failed Auths ### AIE Rule ID: 1270 Attack Lifecycle: Lateral Movement ### Rule Description: The same internal account unsuccessfully attempts to authenticate to multiple hosts within a short period of time. **Common Event:** AIE: Lateral: Numerous and Dispersed Internal Failed Auths **Classification:** Security : Suspicious **Suppression Multiple:** 12 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 5 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: You may want to isolate the Origin Hosts that are performing the activity to determine if the hosts have been compromised. You may also want to investigate the accounts being used if they are "Generic" or if they are known in the company. If known, you may want to reset the passwords of the accounts being used. Use Case: A malicious program is attempting to worm its way across the network with known credentials that might be old and thus the password is failing or with generic credentials like "Admin" or "Root" and default credentials are being attempted. ## Lateral: Numerous Internal Failed Auths ### AIE Rule ID: 1271 Attack Lifecycle: Lateral Movement ### Rule Description: Multiple, unique unsuccessful login attempts from an internal host are made on the same impacted host within a short period of time. **Common Event:** AIE: Lateral: Numerous Internal Failed Auths **Classification:** Security : Suspicious **Suppression Multiple:** 12 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 5 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Determine if the Origin Host is known or unknown. If unknown, you may want to isolate the host until an investigation can determine if a compromise has occurred. You may also want to determine if the accounts are active in your environment and if so, you may want to change the name of generic accounts and or perform password resets. Use Case: A malicious individual has a list of accounts and is attempting to authenticate with one of these accounts on a single machine, with no successful authentication observed. Configuration: Depending on the environment the amount of unique values may need to be increased for Rule Block 1. An authentication failure log is created by each domain controller in your environment. ## Lateral: Password Modified by Admin ### AIE Rule ID: 1272 Attack Lifecycle: Lateral Movement ### Rule Description: Privileged user changes the password of another account. **Common Event:** AIE: Lateral: Password Modified by Admin **Classification:** Security : Suspicious **Suppression Multiple:** 60 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 3 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Verify the change control procedure has been followed and that this user's password was reset according to standards and guidelines. If your investigation reveals that the account is known and should be in the Privilege User List, you may use a smart response plugin to automatically add the user to the list to further reduce future false positives. Use Case: A compromised privileged account can change another credential's password to further gain access to systems, applications like databases, and or data. A scenario would be that a compromised IT credential is being used to change the password of a known HR user account to gain access to data owned by HR but restricted to members of IT. The attacker would then change the password of the HR account and use that account to access the data owned by HR. Configuration: 1. Populate the "Privileged Users" List. a. Recommended that you review this list for accuracy at least quarterly. ## Lateral: Privilege Escalation after Attack ### AIE Rule ID: 1273 Attack Lifecycle: Lateral Movement ### Rule Description: Compromised host event followed by a new account created or account modified on the same host. **Common Event:** AIE: Lateral: Privilege Escalation after Attack **Classification:** Security : Compromise **Suppression Multiple:** 2 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 3 **Log Sources (minimum)** Intrusion Detection System Host Logs **Log Sources (recommended)** Intrusion Detection System LogRhythm Sysmon **AIE Rule Additional Details** Action: The cost and recovery time of a compromise grows exponentially with each stage of the attack cycle, so it is imperative to stop the attack as early as possible. These rules indicate that the attacker has moved past the initial stages and is consolidating their beachhead. After the attack is stopped, it is very important to do a full sweep of the network for other signs of continued infection. Use Case: An IDS has detected some sort of hacking activity. Later, the same impacted host has an account created or permissions granted, indicating a likely compromise. ## Compromise: CloudAI Multiple User Threat Events ### AIE Rule ID: 1278 Attack Lifecycle: Initial Compromise ### Rule Description: CloudAI multiple high user threat scores. **Common Event:** AIE: Compromise: CloudAI Multiple User Threat Even **Classification:** Security : Suspicious **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** LogRhythm UEBA Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** Action: Evaluate the anomalous user in CloudAI dashboard or CloudAI dashboard widgets to decide if the anomaly is benign or suspicious. Use Case: A user's behavior has changed sufficiently that the user's behavior is anomalous and has multiple recent observations, as decided by CloudAI. This could indicate an ongoing risk that should be investigated. Configuration: The LogRhythm CloudAI service populates CloudAI rules to find anomalous user activity based on many indicators. LogRhythm CloudAI data is needed for this AI Engine rule - for more information please contact your Customer Relationship Manager. Adjust the threshold count according to your company's assessment of acceptable risk. To adjust the count: 1. Open the rule in AI Engine Rule Wizard. 2. On the Threshold Rule Block, Right Click and select Properties. 3. Select the Thresholds Tab. 4. Change the value under Threshold. 5. Click OK to close the AI Engine Rule Block Wizard. 6. Click OK to close the AI Engine Rule Wizard. ## Recon: Disabled Account Auth Failures ### AIE Rule ID: 1279 Attack Lifecycle: Recon and Planning ### Rule Description: Recently disabled or deleted account unsuccessfully tries to authenticate or access resources. **Common Event:** AIE: Recon: Disabled Account Auth Failures **Classification:** Security : Suspicious **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 5 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Decide if access attempt is known or unknown by confirming with the credential owner's supervisor. If unknown, decide where access attempts are being made and you will want to isolate the host and or block the origin IP address. Use Case: A malicious process is trying to use credentials that are disabled. Another use case would be an employee is terminated or has left an organization and shortly after tries to access network resources and fails. Configuration: If using windows audit logging make sure audit account management is turned on for successes and audit account logon events is turned on for success and failures in the local security policy. Optional: You can tune the rule to focus on high value accounts by adding a user list filter. ## Lateral: Internal Attack then Account Creation ### AIE Rule ID: 1267 Attack Lifecycle: Lateral Movement ### Rule Description: Attack or compromise event from an internal host followed by an account creation on the victim host. **Common Event:** AIE: Lateral: Internal Attack then Account Creatio **Classification:** Security : Compromise **Suppression Multiple:** 6 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 4 **Log Sources (minimum)** Intrusion Detection System and Active Directory or LDAP **Log Sources (recommended)** Intrusion Detection System and Host Logs **AIE Rule Additional Details** Action: Because the attack has already progressed to an advanced stage, it is imperative to stem the damage and stop the attack as early as possible. These rules indicate that the attacker has moved past the initial stages, is spreading throughout the network, and likely has already begun to pillage. After the attack is stopped, use the logs from the alarm to help with a full sweep of the network for other signs of continued infection. Use Case: A system is successfully attacked, and the attacker then creates a new account on the system to maintain access. ## Compromise: Auth After Numerous Failed Auths ### AIE Rule ID: 1253 Attack Lifecycle: Initial Compromise ### Rule Description: Multiple external unique login attempts are seen on the same impacted host within a short period of time, followed by a successful authentication. **Common Event:** AIE: Compromise: Auth After Numerous Failed Auths **Classification:** Security : Compromise **Suppression Multiple:** 12 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 2 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Investigate the source of the authentication and if it's a known user source or new. If known, verify with the user if they are having trouble authenticating. If new source, you may want to deny or isolate the source until you can determine if the source is something that should be trusted or not. You may want to also investigate if the source has attempted any other authentications using other credentials to aid in further determining if the source is suspicious. If the source is suspicious you should disable the account being used until the investigation can determine how the account was possibly compromised. You should also reset the password of the possibly compromised account. Use Case: A malicious individual has a list of email addresses from the company and is attempting to authenticate with one of these accounts from a single machine, followed by a successful authentication from the same machine. Configuration: You may want to exclude your cloud providers' subnets or define them as part of your entity structure to list them as internal to reduce false positives. ## Attainment: Corroborated Account Anomalies ### AIE Rule ID: 1246 Attack Lifecycle: Target Attainment ### Rule Description: 3 or more unique behavioral anomalies for a given user within a 3-hour period. **Common Event:** AIE: Attainment: Corroborated Account Anomalies **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** High **False Positive Probability:** 3 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** AI Engine Events **AIE Rule Additional Details** Action: This alarm may show a heightened security issue that should be prioritized to decide if a compromise is likely. Use Case: An account has been compromised. Configuration: This rule needs the following rules to be enabled: 1) Compromise: Abnormal Process Activity, ID 1248 2) Lateral: Abnormal Auth Behavior, ID 1260 3) C2: Abnormal Origin Location, ID 1247 4) Attainment: Abnormal File Access, ID 1245 ## C2: Abnormal Origin Location ### AIE Rule ID: 1247 Attack Lifecycle: Command and Control ### Rule Description: First tracks geographic locations for logins. Afterwards, triggers when a new origin location is seen for a user. **Common Event:** AIE: C2: Abnormal Origin Location **Classification:** Security : Attack **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** High **False Positive Probability:** 8 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Contact the user to decide if this activity is known or unknown. If unknown, you may want to disable the account until an investigation can decide if the account is compromised. You may also want to change the password of the account. Use Case: A user's credentials were compromised, and the attacker authenticates in from an area that is not common. ## Compromise: Abnormal Process Activity ### AIE Rule ID: 1248 Attack Lifecycle: Initial Compromise ### Rule Description: First tracks processes associated with a user. Afterwards, triggers if drastically different processes are observed from the user. **Common Event:** AIE: Compromise: Abnormal Process Activity **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** High **False Positive Probability:** 8 **Log Sources (minimum)** Host Logs **Log Sources (recommended)** LogRhythm Sysmon **AIE Rule Additional Details** Action: Decide if the process is known or unknown. On Windows systems, you may want to run a program like Microsoft Windows Sysinternals Process Monitor with Virus Total query enabled. If the process is suspicious or known to be malicious, you may want to isolate the system until an investigation can decide if a compromise has occurred. Use Case: A user's credentials are compromised. The attacker uses the credentials to start a remote access toolkit (RAT) process on the user's machine. ## C2: Blacklist Location Auth ### AIE Rule ID: 1249 Attack Lifecycle: Command and Control ### Rule Description: Authentication success from a blacklisted location. **Common Event:** AIE: C2: Blacklist Location Auth **Classification:** Security : Compromise **Suppression Multiple:** 3600 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Verify with the user if they are using any 3rd party VPN service that is not supported by the company where they might be routed through a black listed country. Also, verify with the user what their external IP address is. If found that the user is not trying to connect through a black listed country, you should disconnect the active VPN session and disable the user account until an investigation can be performed and decide how the attempt was being made. Some well-known 3rd party VPN services are: NORDVPN, Private Internet Access, Express VPN, TORGUARD, Anonymizer, IPREDATOR, SLICKVPN, MULLVAD, BLACKVPN, VPNAREA, IPVANISH, IVPN, LIQUIDVPN, SMARTVPN, PRIVATEVPN, CRYPTOSTORM, BUFFERED and many more. Use Case: An attacker is using a compromised account to authenticate from a location considered unauthorized. Configuration: 1. Enable Geolocation. 2. Populate the "Network: Blacklisted Countries" List. a. Recommended that you review this list for accuracy at least quarterly. ## Compromise: Concurrent VPN from Multiple Locations ### AIE Rule ID: 1250 Attack Lifecycle: Initial Compromise ### Rule Description: Multiple authentication successes from the same origin login are observed from different geographic regions within a given time (default 3 hours). **Common Event:** AIE: Compromise: Concurrent Authentication Success **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** Authentication Log Sources **Log Sources (recommended)** N/A **AIE Rule Additional Details** Action: Verify with the user by calling them and verify if this activity is known. If unknown, disconnect active user sessions and disable the user account until you can determine how the other authentication session was initiated. Use Case: An attacker has obtained the credentials of a user that currently logged on externally and authenticates with the compromised credentials from a different geographical location. Configuration: Enable Geolocation. ## Lateral: Admin Password Modified ### AIE Rule ID: 1262 Attack Lifecycle: Lateral Movement ### Rule Description: User changes the password of a different privileged user account. **Common Event:** AIE: Lateral: Admin Password Modified **Classification:** Security : Compromise **Suppression Multiple:** 60 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 3 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Verify the admin was aware of the password change. Also verify change control procedure has been followed and that this user's password was reset according to standards and guidelines. Use Case: A compromised privileged account can change another privileged account credentials to further gain access to systems, applications like databases, and or data. A scenario would be that a compromised IT credential is being used to change the password of a known database privilege user to gain access to data on a database server that is restricted to members of IT. The attacker would then change the password of the privilege user account and use that account to access the data. Configuration: 1. Populate the "Privileged Users" List. a. Recommended that you review this list for accuracy at least quarterly. ## Compromise: Windows RunAs Privilege Escalation ### AIE Rule ID: 1252 Attack Lifecycle: Initial Compromise ### Rule Description: User not in the LogRhythm List "Privileged Users" chooses to Run a Windows program as an administrator using the "Run as administrator" option. **Common Event:** AIE: Compromise: Windows RunAs Privilege Escalatio **Classification:** Security : Compromise **Suppression Multiple:** 3600 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 3 **Log Sources (minimum)** Windows Host Logs **Log Sources (recommended)** Active Directory or LDAP **AIE Rule Additional Details** Action: Decide if the account being elevated is known or unknown on the Impacted Host. If unknown, you may want to isolate the host until an investigation can decide if compromise is likely. If your investigation reveals that the account is known and should be in the Privilege User List, you may use a smart response plugin to automatically add the user to the list to further reduce future false positives. To further contextualize the alert, you may want to pivot on Vendor Message ID 4624 and 4688. Use Case: You have hardened all the security settings on your internal chat sever (e.g., Microsoft Lync) and someone is trying to install a MITM spyware to capture chats. The malicious user needs to run the spyware as administrator to access various registry settings needed to complete the attack. Configuration: 1. Populate the "Privileged Users" List. a. Recommended that you review this list for accuracy at least quarterly. ## Recon: Multiple Lockouts ### AIE Rule ID: 1283 Attack Lifecycle: Recon and Planning ### Rule Description: An account is locked out 2 or more times per hour. **Common Event:** AIE: Recon: Multiple Lockouts **Classification:** Security : Reconnaissance **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 3 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Accounts under attack should be temporarily disabled while under investigation. Attack sources should be blocked via security system or other security device. Use Case: In large companies it sometimes can be daunting and tedious to sift through the "noise" of potential operational events of interest. This alarm alerts when accounts are locked out 3 or more times in an hour instead of every time an account is locked out. ## Compromise: Auth After Security Event ### AIE Rule ID: 1254 Attack Lifecycle: Initial Compromise ### Rule Description: An observed attack, compromise, or other security event followed by successful access or authentication from the attacking host. **Common Event:** AIE: Compromise: Auth After Security Event **Classification:** Security : Compromise **Suppression Multiple:** 2 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 3 **Log Sources (minimum)** Intrusion Detection System Host Logs **Log Sources (recommended)** Intrusion Detection System LogRhythm Sysmon **AIE Rule Additional Details** Action: If a compromise of the account is suspected you may want to disable the account until an investigation can determine if the account was compromised. You may want to run an investigation on the Origin Host of the IDS detection and determine if it is known to the company or unknown. If unknown, you may want to deny the IP address and or range of IPs on the company firewall. Use Case: An IDS has detected some sort of hacking activity from an external host. Later, the same external host is seen successfully authenticating with an internal host, indicating a successful network penetration. ## Compromise: Distributed Brute Force ### AIE Rule ID: 1255 Attack Lifecycle: Initial Compromise ### Rule Description: A successful brute force authentication -- multiple failed authentication attempts from different external hosts to the same host using the same origin login, followed by an authentication success. **Common Event:** AIE: Compromise: Distributed Brute Force **Classification:** Security : Compromise **Suppression Multiple:** 12 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 1 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs, Web Server Logs **AIE Rule Additional Details** Action: This rule fires when the attacker could compromise at least one account. In this case, it is vital to quickly contain the compromise by disconnecting infected hosts, disabling the compromised account, and blocking the attacker's access -- organizations should have an incident response plan for a compromise. Also, after stopping the active attack, forensics will need to be conducted to ensure that an implant isn't hidden in the network, information wasn't stolen, or other accounts were compromised. Use Case: An attacker knows a login ID to a specific host and repeatedly attempts to authenticate using various passwords from different origin hosts to mask the password guessing activity, and eventually successfully authenticates. Configuration: In Windows, activate Audit Account Management for successes in the Group/Local Security Policy. ## Compromise: External Brute Force Auths ### AIE Rule ID: 1256 Attack Lifecycle: Initial Compromise ### Rule Description: Successful authentication after multiple failed attempts from different external origin hosts to the same impacted host. **Common Event:** AIE: Compromise: External Brute Force Auths **Classification:** Security : Compromise **Suppression Multiple:** 12 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 5 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs, Web Server Logs, VPN **AIE Rule Additional Details** Action: Investigate if the login is valid. If so, you may wish to change the password of the account and utilize a complex and lengthy password to minimize brute force guessing success. If the login is found to be "generic" like "Admin" or "Root", etc. you may want to rename the account to minimize brute forcing of generic login identities. For known accounts, deploy multi factor authentication to minimize the effectiveness of brute force password guessing and exposed credentials through 3rd party breaches. Use Case: An attacker knows a login id to a specific host and repeatedly attempts to authenticate using various passwords from the same origin host to brute force authentication. The login id could've been obtained as part of a 3rd party data breach or an attempt to use default credentials like "Admin, Administrator, Root", etc. Configuration: To reduce false positives of failed authentications of login identities that are not applicable to your organization and would otherwise be considered generic, you may want to include a known user list to this rule. ## Compromise: Lateral Movement With Account Sweep ### AIE Rule ID: 1257 Attack Lifecycle: Initial Compromise ### Rule Description: The same internal account is used to attempt to authenticate to multiple hosts within a short period of time, followed by a successful authentication. **Common Event:** AIE: Compromise: Lateral Movement With Account Swe **Classification:** Security : Compromise **Suppression Multiple:** 12 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 5 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: You may want to isolate the Origin Host that is performing the activity to determine if the host has been compromised. You may also want to investigate the accounts being used if they are "Generic" or if they are known in the company. If known, you may want to reset the passwords of the accounts being used. Use Case: A malicious program is attempting to worm its way across the network with known credentials that might be old and thus the password is failing or with generic credentials like "Admin" or "Root" and default credentials are being attempted. ## Corruption: Audit Disabled by Admin ### AIE Rule ID: 1258 Attack Lifecycle: Corruption ### Rule Description: Login by an administrator followed by disabling of an audit process. **Common Event:** AIE: Corruption: Audit Disabled by Admin **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** Host Logs **Log Sources (recommended)** LogRhythm Sysmon **AIE Rule Additional Details** Action: If audits are being disabled, it is highly likely that malicious activity is taking place. Immediately launch LogRhythm investigations on the Log Source where this is occurring. Use Case: A disgruntled administrator plans on malicious activity and disables auditing beforehand to ensure the activity is not logged. Configuration: 1. Populate the "Privileged Users" List. a. Recommended that you review this list for accuracy at least quarterly. ## Disruption: Files Deleted by Admin ### AIE Rule ID: 1259 Attack Lifecycle: Disruption ### Rule Description: Privileged user login followed by multiple file deletions, indicating the administrator may be destroying large amounts of data. **Common Event:** AIE: Disruption: Files Deleted by Admin **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** Host Logs **Log Sources (recommended)** Active Directory or LDAP, LogRhythm Sysmon **AIE Rule Additional Details** Action: Determine the Origin Host and if the host is known. If unknown, you may want to isolate the host until an investigation can decide if a compromise has occurred. You may also want to contact the account owner and or the file owners to decide if the action is known or unknown to further decide if a compromise is likely. Use Case: A destructive malicious application or a possible disgruntled administrator wants to disrupt company workflow by deleting commonly used files on a shared drive. Configuration: 1. Populate the "Privileged Users" List. a. Recommended that you review this list for accuracy at least quarterly. ## Recon: Linux sudo Privilege Escalation ### AIE Rule ID: 1251 Attack Lifecycle: Recon and Planning ### Rule Description: User not in the LogRhythm list "Privileged Users" and not in the local 'sudoers' file tries to use sudo on a Linux host. **Common Event:** AIE: Recon: Linux sudo Privilege Escalation **Classification:** Security : Reconnaissance **Suppression Multiple:** 3600 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 5 **Log Sources (minimum)** Linux Host Logs **Log Sources (recommended)** Active Directory or LDAP **AIE Rule Additional Details** Action: Decide if the account being used is known or unknown on the Impacted Host. If unknown, you may want to isolate the host to decide if compromise is likely. If your investigation reveals that the account is known and should be in the Privilege User List, you may use a smart response plugin to automatically add the user to the list to further reduce future false positives. Use Case: An attacker is testing their access by trying to run malicious code on a Linux box without super user privileges. Configuration: 1. Populate the "Privileged Users" List. a. Recommended that you review this list for accuracy at least quarterly. ## Compromise: CloudAI and Recent User Location Data Observed ### AIE Rule ID: 1307 Attack Lifecycle: Initial Compromise ### Rule Description: CloudAI anomalous authentication location activity observation and AI Engine observed authentication events involving location for the same user identity. **Common Event:** AIE: Compromise: CloudAI and Recent User Location **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 5 **Log Sources (minimum)** LogRhythm UEBA Events **Log Sources (recommended)** VPN Logs **AIE Rule Additional Details** Action: Evaluate the anomalous user in CloudAI dashboard or CloudAI dashboard widgets to decide if the anomaly is benign or suspicious. Additionally, investigate the User (Origin) Identity around the time of the observed CloudAI anomaly for any suspicious authentications involving locations. Use Case: A user's authentication location behavior has changed sufficiently that the user's behavior is anomalous as decided by CloudAI. Detailed locations of the user authentications are needed to aid the analyst in deciding if the locations are suspicious. Configuration: The LogRhythm CloudAI service populates CloudAI rules to find anomalous user activity based on many indicators. LogRhythm CloudAI data is needed for this AI Engine rule - for more information please contact your Customer Relationship Manager. This rule uses the "CloudAI: Ignore for 24 Hours" list. Place user identities that you may want to ignore for 24 hours here that are generating many events for a known reason that would otherwise cause this rule to event and alarm if configured to do so. Adjust the threat score according to your company's assessment of acceptable risk. To adjust the score: 1. Open the rule in AI Engine Rule Wizard. 2. On the Threshold Rule Block, Right Click and select Properties. 3. Select the Thresholds Tab. 4. Change the value under Threshold. 5. Click OK to close the AI Engine Rule Block Wizard. 6. Click OK to close the AI Engine Rule Wizard. ## Compromise: Security Event then Process Starting ### AIE Rule ID: 1300 Attack Lifecycle: Initial Compromise ### Rule Description: Security Classification of Compromise, Reconnaissance, Attack event against a host followed by a non-whitelisted process starting up on the same host, indicating a compromise. **Common Event:** AIE: Compromise: Security Event then Process Start **Classification:** Security : Compromise **Suppression Multiple:** 12 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 5 **Log Sources (minimum)** Host Security Logs/AV/IDS/IPS **Log Sources (recommended)** NextGen Firewall **AIE Rule Additional Details** Action: Run an investigation for the impacted host for activity around the time of the alarm. Find the process that started on the impacted host and confirm that it is a known non-malicious process and that the process action was known. If known, add the process in accordance to your company's change management process to the LogRhythm Whitelisted Processes list. If unknown, follow your company's incident response plan. Use Case: An attacker scans a machine for a vulnerability. The vulnerability is exploited, and a new malicious process is started up on the target machine. Configuration: This rule uses two lists named "Vulnerability Scanners" and "Network: Whitelisted Processes." The following is information on configuring the lists for this rule: 1. Populate the "Vulnerability Scanners" list with the DNS, NetBios, and IP address where applicable for each vulnerability scanner you may have in your environment. 2. Populate the "Network: Whitelisted Processes" with process names that are trusted in your environment. For both list items, you should review the lists quarterly for completeness. Additionally, you may want to whitelist trusted users in User Origin such as System, Network Service, Local Service, etc. ## Compromise: System Time Change ### AIE Rule ID: 1301 Attack Lifecycle: Initial Compromise ### Rule Description: An attack or compromise events followed by time change activity on the same impacted host. **Common Event:** AIE: Compromise: System Time Change **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 5 **Log Sources (minimum)** Host Security Logs/IDS/IPS **Log Sources (recommended)** NextGen Firewall **AIE Rule Additional Details** Action: Investigate the impacted system to decide if the system was successfully compromised. You may want to look for how the system time was changed, i.e. if it was due to a user changing the time or if it was a potentially malicious process changing the time. If malicious, follow your company's security incident response process. Use Case: An attacker successfully compromises a system and then changes the system time to obfuscate their activities. This activity could be a person on keyboard or automated malware. ## Compromise: Unusual Auth then Unusual Process ### AIE Rule ID: 1302 Attack Lifecycle: Initial Compromise ### Rule Description: First tracks normal hosts accessed by a user and which processes are used. Afterwards, triggers when the user authenticates to a different host and starts a process that was not seen in the same learning period. **Common Event:** AIE: Compromise: Unusual Auth then Unusual Process **Classification:** Security : Compromise **Suppression Multiple:** 4 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** High **False Positive Probability:** 5 **Log Sources (minimum)** Host Security Logs/AD/LDAP **Log Sources (recommended)** LogRhythm Sysmon **AIE Rule Additional Details** Action: Investigate the impacted host to decide if the authentication is known and the process is non-malicious, and activity is authorized. If unauthorized or malicious activity is found, follow your company's security incident response process. Use Case: Compromised credentials are being used to perform unauthorized access and compromise the impacted host by running unauthorized software tools, applications, or malware to corrupt, disrupt or exfil data from the host impacted. Configuration: 1) It is recommended to not enable alarming on this rule until this rule has a chance to learn the environment and events being generated are minimal and relevant. You should check on this rule by running the Summary of AI Engine Events report weekly. 2) This is a learning Whitelist rule. It is recommended to re-tune this rule quarterly or when false negatives occur by opening the rule and right click on each of the Whitelist Profiles and select "Resync from Rule Block." It is also recommended to disable alarming when resyncing. ## Compromise: Security Event then Scheduled Task ### AIE Rule ID: 1303 Attack Lifecycle: Initial Compromise ### Rule Description: A security event on a host followed by creation of a scheduled process. **Common Event:** AIE: Compromise: Sec Event then Scheduled Task **Classification:** Security : Compromise **Suppression Multiple:** 6 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 6 **Log Sources (minimum)** Host Security Logs/AV/IDS/IPS **Log Sources (recommended)** Sysmon/CarbonBlack **AIE Rule Additional Details** Action: Investigate the host to gather more context around what was done as part of the Scheduled Task, what security classification preceded it and what the origin host is. If the origin and impacted host are the same, investigate the security classification further to decide what was decided to be a security event and if the detection is a "True Positive" or "False Positive." Use Case: A security classification was seen affecting the same host where a scheduled task was started. This tactic of using Scheduled Task is common in malicious attack scenarios for the attacker to execute malicious code remotely on the host as a privileged user. ## Lateral: Locally Created and Used ### AIE Rule ID: 1304 Attack Lifecycle: Lateral Movement ### Rule Description: An account is created on a host and then used shortly thereafter on the same host. **Common Event:** AIE: Lateral: Locally Created and Used **Classification:** Security : Compromise **Suppression Multiple:** 2 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 5 **Log Sources (minimum)** Host Security Logs **Log Sources (recommended)** Single Sign On Logs **AIE Rule Additional Details** Action: Investigate the local account to decide what it was used for. Run an investigation around the Origin User of the account creation activity to see if any other unusual activity is seen. Use Case: Local account creation is atypical in a corporate environment and can be used for malicious purposes. Local accounts are typically used to bypass domain authentication and domain policies creating an elevated security risk. ## Recon: Failed Distributed Account Probe ### AIE Rule ID: 1281 Attack Lifecycle: Recon and Planning ### Rule Description: The same external account unsuccessfully attempts to authenticate to multiple hosts within a short period of time. **Common Event:** AIE: Recon: Failed External Auth to Multiple Hosts **Classification:** Security : Reconnaissance **Suppression Multiple:** 6 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 3 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Responses to 'failure' alarms should include hardening the potential victim host and account and blocking the attacker. It is also useful to determine if the attack is a determined effort to compromise the network or just a passing probe. Perform follow-up investigations for additional logs generated by the attacker and victim. Remember that a failure alarm may mean that the attacker was still successful in other attempts. Use Case: A malicious individual finds a list of users and credentials from a recent data dump. The attacker then attempts to use these credentials on several different hosts, with no successful authentication observed. ## Disruption: Critical Windows Binaries Modified/Deleted ### AIE Rule ID: 1306 Attack Lifecycle: Disruption ### Rule Description: A change has been made to any executable in the C:\\windows\\system32 or C:\\Windows\\Syswow64\\ folder. **Common Event:** AIE: Disruption: Critical Windows Binaries Mod/Del **Classification:** Security : Compromise **Suppression Multiple:** 60 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 1 **Log Sources (minimum)** LogRhythm Sysmon: File Monitor **Log Sources (recommended)** N/A **AIE Rule Additional Details** Action: Investigate the impacted host and decide if the binary is suspicious or known malicious. If found to be suspicious or known malicious, follow your company's normal security incident response process. Use Case: An attacker is trying to setup the Sticky Keys exploit, renaming sethc.exe to cmd.exe. Changes may also be legitimate during Windows Updates as an example. Configuration: 1) This rule needs the LogRhythm System Agent File Monitoring Event to be configured along with a FIM Policy to detect Add, Delete, Modify and Permission changes of files found in System32 and SysWOW64. 2) With the introduction of User (Origin), you will need to configure additional tuning to the Primary Criteria in Rule Block 1 to reduce false positives around the Windows System Account performing normally. a. Open Rule Block 1 and edit the existing filter to add And Previous User (Origin) Is Not: system. System should be what is equivalent to the local system account. ## Progression: to Target Attainment ### AIE Rule ID: 1297 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as any earlier stage is followed by Target Attainment with the same user or host. **Common Event:** AIE: Progression: to Target Attainment **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. ## Compromise: CloudAI and Location Watch List ### AIE Rule ID: 1308 Attack Lifecycle: Initial Compromise ### Rule Description: CloudAI anomalous authentication location activity observation and AI Engine observed authentication for the same user identity events involving the location watch list. **Common Event:** AIE: Compromise: CloudAI and Location Watch List **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 4 **Log Sources (minimum)** LogRhythm UEBA Events **Log Sources (recommended)** VPN Logs **AIE Rule Additional Details** Action: Evaluate the anomalous user in CloudAI dashboard or CloudAI dashboard widgets to decide if the anomaly is benign or suspicious. Additionally, investigate the User (Origin) Identity around the time of the observed CloudAI anomaly for any suspicious authentications involving locations. Use Case: A user's authentication location behavior has changed sufficiently that the user's behavior is anomalous as decided by CloudAI. Detailed locations of the user authentications are needed to aid the analyst in deciding if the locations are suspicious. Configuration: The LogRhythm CloudAI service populates CloudAI rules to find anomalous user activity based on many indicators. LogRhythm CloudAI data is needed for this AI Engine rule - for more information please contact your Customer Relationship Manager. This rule uses two lists, the "CloudAI: Ignore for 24 Hours" and "Location Watch List". The following is how to configure and use the rule: 1. The "CloudAI: Ignore for 24 Hours" list. Place user identities that you may want to ignore for 24 hours here that are generating many events for a known reason that would otherwise cause this rule to event and alarm if configured to do so. 2. Populate the "Location Watch List" List. a. Recommended that you review this list for accuracy at least quarterly. Adjust the threshold score according to your company's assessment of acceptable risk. To adjust the score: 1. Open the rule in AI Engine Rule Wizard. 2. On the Threshold Rule Block, Right Click and select Properties. 3. Select the Thresholds Tab. 4. Change the value under Threshold. 5. Click OK to close the AI Engine Rule Block Wizard. 6. Click OK to close the AI Engine Rule Wizard. ## Compromise: CloudAI and User Recently Added to a Privileged Group ### AIE Rule ID: 1309 Attack Lifecycle: Initial Compromise ### Rule Description: CloudAI anomalous user activity observation and AI Engine observed user identity recently added to a group on the privileged group list. **Common Event:** AIE: Compromise: CloudAI and User Recently Added t **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 4 **Log Sources (minimum)** LogRhythm UEBA Events/Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Evaluate the anomalous user in CloudAI dashboard or CloudAI dashboard widgets to decide if the anomaly is benign or suspicious. Use Case: A user's behavior has changed sufficiently that the user's behavior is anomalous as decided by CloudAI and the user was recently added to a group on the privileged group list, showing more risk and possible insider threat. Configuration: The LogRhythm CloudAI service populates CloudAI rules to find anomalous user activity based on many indicators. LogRhythm CloudAI data is needed for this AI Engine rule - for more information please contact your Customer Relationship Manager. This rule uses two lists, the "CloudAI: Ignore for 24 Hours" and "Privileged Groups". The following is how to configure and use the rule: 1. The "CloudAI: Ignore for 24 Hours" list. Place user identities that you may want to ignore for 24 hours here that are generating many events for a known reason that would otherwise cause this rule to event and alarm if configured to do so. 2. It is recommended that you populate the Privileged Groups List with the following values. Note: Your deployment may vary, and the following groups may or may not be available. a. Any "Admin" named group b. account operators c. adm d. administrators e. bin f. domain admins g. enterprise admins h. lpadmin i. sudoers j. sys k. wheel 3. Recommended that you review this list for accuracy at least quarterly. Adjust the threshold score according to your company's assessment of acceptable risk. To adjust the score: 1. Open the rule in AI Engine Rule Wizard. 2. On the Threshold Rule Block, Right Click and select Properties. 3. Select the Thresholds Tab. 4. Change the value under Threshold. 5. Click OK to close the AI Engine Rule Block Wizard. 6. Click OK to close the AI Engine Rule Wizard. ## Compromise: CloudAI and User related Security Classification Event ### AIE Rule ID: 1310 Attack Lifecycle: Initial Compromise ### Rule Description: CloudAI anomalous user activity observation and AI Engine observed user activity associated with a security classification. **Common Event:** AIE: Compromise: CloudAI and User related Security **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 3 **Log Sources (minimum)** LogRhythm UEBA Events/Any Log Source **Log Sources (recommended)** N/A **AIE Rule Additional Details** Action: Evaluate the anomalous user in CloudAI dashboard or CloudAI dashboard widgets to decide if the anomaly is benign or suspicious. Additionally, evaluate the User (Origin) Identity activity associated with any security classification around the time of the CloudAI anomalous user activity. Use Case: A user's behavior has changed sufficiently that the user's behavior is anomalous as decided by CloudAI and the user's activity is associated with a security classification, showing more risk and possible insider threat. Configuration: The LogRhythm CloudAI service populates CloudAI rules to find anomalous user activity based on many indicators. LogRhythm CloudAI data is needed for this AI Engine rule - for more information please contact your Customer Relationship Manager. Adjust the threshold score according to your company's assessment of acceptable risk. To adjust the score: 1. Open the rule in AI Engine Rule Wizard. 2. On the Threshold Rule Block, Right Click and select Properties. 3. Select the Thresholds Tab. 4. Change the value under Threshold. 5. Click OK to close the AI Engine Rule Block Wizard. 6. Click OK to close the AI Engine Rule Wizard. ## Compromise: CloudAI Threat Event and Identity Lists ### AIE Rule ID: 1336 Attack Lifecycle: Initial Compromise ### Rule Description: CloudAI anomalous user activity observation and AI Engine observed user on the following user lists: Privileged Users Executive Users Watched Users **Common Event:** AIE: Compromise: CloudAI Threat Event and Identity **Classification:** Security : Suspicious **Suppression Multiple:** 60 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 2 **Log Sources (minimum)** LogRhythm UEBA Events/Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Evaluate the anomalous user in CloudAI dashboard or CloudAI dashboard widgets to decide if the anomaly is benign or suspicious. Additionally, evaluate the User (Origin) Identity activity associated with any security classification around the time of the CloudAI anomalous user activity. Use Case: A user's behavior has changed sufficiently that the user's behavior is anomalous as decided by CloudAI and the user is on one of the configured user lists, showing more risk and possible insider threat. Configuration: The LogRhythm CloudAI service populates CloudAI rules to find anomalous user activity based on many indicators. LogRhythm CloudAI data is needed for this AI Engine rule - for more information please contact your Customer Relationship Manager. This rule uses four lists: CloudAI: Ignore for 24 Hours Privileged Users Executive Users Watched Users The following is how to configure and use the rule: 1. The "CloudAI: Ignore for 24 Hours" list. Place user identities that you may want to ignore for 24 hours here that are generating many events for a known reason that would otherwise cause this rule to event and alarm if configured to do so. 2. Populate the "Watched Users", "Privileged Users", and "Executive Users" lists. a. Recommended that you review this list for accuracy at least quarterly. Adjust the threshold score according to your company's assessment of acceptable risk. To adjust the score: 1. Open the rule in AI Engine Rule Wizard. 2. On the Threshold Rule Block, Right Click and select Properties. 3. Select the Thresholds Tab. 4. Change the value under Threshold. 5. Click OK to close the AI Engine Rule Block Wizard. 6. Click OK to close the AI Engine Rule Wizard. ## Compromise: CloudAI Threat Event ### AIE Rule ID: 1312 Attack Lifecycle: Initial Compromise ### Rule Description: Any CloudAI anomalous user activity observation and event generation of the observation. **Common Event:** AIE: Compromise: CloudAI Threat Event **Classification:** Security : Suspicious **Suppression Multiple:** 60 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 5 **Log Sources (minimum)** LogRhythm UEBA Events/Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Evaluate the anomalous user in CloudAI dashboard or CloudAI dashboard widgets to decide if the anomaly is benign or suspicious. Additionally, evaluate the User (Origin) Identity activity associated with any security classification around the time of the CloudAI anomalous user activity. Use Case: A user's behavior has changed sufficiently that the user's behavior is anomalous as decided by CloudAI and the user is on the watch list, showing more risk and possible insider threat. This rule is best suited to enable and to create events in the event database. This will likely aide you in the following ways: • Events generated can be displayed on the Web UI Dashboards. • Events can be used for reporting and compliance purposes. • Events can be used to confirm that AI Engine did process the CloudAI observation. • Rule can be used to event and alarm on other observations that are not already accounted for in other AI Engine rules. Configuration: The LogRhythm CloudAI service populates CloudAI rules to find anomalous user activity based on many indicators. LogRhythm CloudAI data is needed for this AI Engine rule - for more information please contact your Customer Relationship Manager. Enable the rule to generate CloudAI observation events into the events database. ## Exfiltration: CloudAI and File (NGFW) Detection ### AIE Rule ID: 1490 Attack Lifecycle: Exfil ### Rule Description: Any CloudAI anomalous user activity observation and important file activity observed by appliances like Next Generation Firewalls (NGFW). **Common Event:** AIE: Exfiltration: CloudAI and File NGFW Detection **Classification:** Security : Suspicious **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 5 **Log Sources (minimum)** CloudAI/NGFW **Log Sources (recommended)** N/A **AIE Rule Additional Details** Action: Evaluate the anomalous user in CloudAI dashboard or CloudAI dashboard widgets to decide if the anomaly is benign or suspicious. Additionally, evaluate the User (Origin) Identity activity associated with any security classification around the time of the CloudAI anomalous user activity. Use Case: A user's behavior has changed sufficiently that the user's behavior is anomalous as decided by CloudAI. Files in motion that might otherwise be normal is now pulled into question to help determine if data exfil has occurred. This rule is best suited to enable and to create events in the event database. This will likely aide you in the following ways: • Events generated can be displayed on the Web UI Dashboards. • Events can be used for reporting and compliance purposes. • Events can be used to confirm that AI Engine did process the CloudAI observation. • Rule can be used to event and alarm on other observations that are not already accounted for in other AI Engine rules. Configuration: The LogRhythm CloudAI service populates CloudAI rules to find anomalous user activity based on many indicators. LogRhythm CloudAI data is needed for this AI Engine rule - for more information please contact your Customer Relationship Manager. Enable the rule to generate CloudAI observation events into the events database. ## Compromise: Change to Host File ### AIE Rule ID: 1305 Attack Lifecycle: Initial Compromise ### Rule Description: A change has been made to a local 'hosts' file, indicating that an IP has been statically assigned to a hostname. **Common Event:** AIE: Compromise: Change to Host File **Classification:** Security : Compromise **Suppression Multiple:** 3600 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Medium **False Positive Probability:** 1 **Log Sources (minimum)** LogRhythm Sysmon: File Monitor **Log Sources (recommended)** N/A **AIE Rule Additional Details** Action: Investigate the Host File to decide who made the change and confirm if the change was approved or if an unknown, malicious process performed the change to the Host File. If found to be unknown or malicious activity was involved in the changing of the Host File, follow your company's normal security incident response process. Use Case: Changes to a local Host File can be used to redirect known good DNS address to possible malicious addresses on the network. Changes to a local Host File can also be used in legitimate operational use to give a DNS name to an IP address that may not have one internally or as a loop back on the system. ## Progression: to Lateral Movement ### AIE Rule ID: 1291 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as an earlier stage is followed by Lateral Movement with the same user or host. **Common Event:** AIE: Progression: to Lateral Movement **Classification:** Security : Attack **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. ## Exfiltration: CloudAI and Sensitive Data (NGFW) Detection ### AIE Rule ID: 1491 Attack Lifecycle: Exfil ### Rule Description: Any CloudAI anomalous user activity observation and sensitive data activity observed by appliances like Next Generation Firewalls (NGFW). **Common Event:** AIE: Exfiltration: CloudAI Sensitive Data NGFW Det **Classification:** Security : Suspicious **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 5 **Log Sources (minimum)** CloudAI/NGFW **Log Sources (recommended)** N/A **AIE Rule Additional Details** Action: Evaluate the anomalous user in CloudAI dashboard or CloudAI dashboard widgets to decide if the anomaly is benign or suspicious. Additionally, evaluate the User (Origin) Identity activity associated with any security classification around the time of the CloudAI anomalous user activity. Use Case: A user's behavior has changed sufficiently that the user's behavior is anomalous as decided by CloudAI. Sensitive file transfer activity detected by key words in the file while in motion that might otherwise be normal is now pulled into question to help determine if data exfil has occurred. This rule is best suited to enable and to create events in the event database. This will likely aide you in the following ways: • Events generated can be displayed on the Web UI Dashboards. • Events can be used for reporting and compliance purposes. • Events can be used to confirm that AI Engine did process the CloudAI observation. • Rule can be used to event and alarm on other observations that are not already accounted for in other AI Engine rules. Configuration: The LogRhythm CloudAI service populates CloudAI rules to find anomalous user activity based on many indicators. LogRhythm CloudAI data is needed for this AI Engine rule - for more information please contact your Customer Relationship Manager. Enable the rule to generate CloudAI observation events into the events database. ## Progression: to Initial Compromise ### AIE Rule ID: 1284 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as Reconnaissance and Planning is followed by Initial Compromise with the same user or host. **Common Event:** AIE: Progression: to Initial Compromise **Classification:** Security : Attack **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. ## Progression: to Command and Control ### AIE Rule ID: 1285 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as Reconnaissance and Planning or Initial Compromise is followed by Command and Control with the same user or host. **Common Event:** AIE: Progression: to Command and Control **Classification:** Security : Attack **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. ## Progression: to Lateral Movement ### AIE Rule ID: 1286 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as an earlier stage is followed by Lateral Movement with the same user or host. **Common Event:** AIE: Progression: to Lateral Movement **Classification:** Security : Attack **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. ## Progression: to Target Attainment ### AIE Rule ID: 1287 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as any earlier stage is followed by Target Attainment with the same user or host. **Common Event:** AIE: Progression: to Target Attainment **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. ## Progression: to Exfil, Corruption, Disruption ### AIE Rule ID: 1288 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as any earlier stage is followed by Exfiltration, Corruption, Disruption with the same user or host. **Common Event:** AIE: Progression: to Exfil, Corruption, Disruption **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. ## Compromise: Log Cleared ### AIE Rule ID: 1299 Attack Lifecycle: Initial Compromise ### Rule Description: A compromise event from an external source followed by the audit log being cleared on the same compromised host. **Common Event:** AIE: Compromise: Log Cleared **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 3 **Log Sources (minimum)** Host Security Logs/AV/IDS/IPS **Log Sources (recommended)** NextGen Firewall **AIE Rule Additional Details** Action: Run investigations for the impacted host and user that performed the activity. Check what process cleared the audit log and make sure it is legitimate. Use Case: An attacker compromises a host and clears the audit log to cover their tracks. ## Progression: to Command and Control ### AIE Rule ID: 1290 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as Reconnaissance and Planning or Initial Compromise is followed by Command and Control with the same user or host. **Common Event:** AIE: Progression: to Command and Control **Classification:** Security : Attack **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. ## Progression: to Exfil, Corruption, Disruption ### AIE Rule ID: 1298 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as any earlier stage is followed by Exfiltration, Corruption, Disruption with the same user or host. **Common Event:** AIE: Progression: to Exfil, Corruption, Disruption **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. ## Progression: to Target Attainment ### AIE Rule ID: 1292 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as any earlier stage is followed by Target Attainment with the same user or host. **Common Event:** AIE: Progression: to Target Attainment **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. ## Progression: to Exfil, Corruption, Disruption ### AIE Rule ID: 1293 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as any earlier stage is followed by Exfiltration, Corruption, Disruption with the same user or host. **Common Event:** AIE: Progression: to Exfil, Corruption, Disruption **Classification:** Security : Compromise **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. ## Progression: to Initial Compromise ### AIE Rule ID: 1294 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as Reconnaissance and Planning is followed by Initial Compromise with the same user or host. **Common Event:** AIE: Progression: to Initial Compromise **Classification:** Security : Attack **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. ## Progression: to Command and Control ### AIE Rule ID: 1295 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as Reconnaissance and Planning or Initial Compromise is followed by Command and Control with the same user or host. **Common Event:** AIE: Progression: to Command and Control **Classification:** Security : Attack **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. ## Progression: to Lateral Movement ### AIE Rule ID: 1296 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as an earlier stage is followed by Lateral Movement with the same user or host. **Common Event:** AIE: Progression: to Lateral Movement **Classification:** Security : Attack **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. ## Recon: Failed Distributed Brute Force ### AIE Rule ID: 1282 Attack Lifecycle: Recon and Planning ### Rule Description: Multiple failed authentication attempts from different external origin hosts to the same impacted host using the same origin login, without seeing an authentication success. **Common Event:** AIE: Recon: Failed External Auth from Multiple Hos **Classification:** Security : Reconnaissance **Suppression Multiple:** 12 **Alarm on Event Occurrence:** No **Environmental Dependence Factor:** Low **False Positive Probability:** 3 **Log Sources (minimum)** Active Directory or LDAP **Log Sources (recommended)** Host Logs **AIE Rule Additional Details** Action: Investigate to determine if the account has been attempted from the Origin Host previously and if not, you may want to disable the account until an investigation can determine if the account was compromised. Also, determine if the Origin Hosts have been seen previously authenticating or if they are new. If determined to be new, you may want to block their IPs and or subnets from being allowed to authenticate to the network. Use Case: An attacker knows a login id to a specific host and repeatedly attempts to authenticate using various passwords from different origin hosts to mask the password guessing activity, and no successful authentication is observed. ## Progression: to Initial Compromise ### AIE Rule ID: 1289 Attack Lifecycle: Progression ### Rule Description: Progression rules monitor for activity moving through the attack lifecycle. This alarm will fire when observed activity categorized as Reconnaissance and Planning is followed by Initial Compromise with the same user or host. **Common Event:** AIE: Progression: to Initial Compromise **Classification:** Security : Attack **Suppression Multiple:** 1 **Alarm on Event Occurrence:** Yes **Environmental Dependence Factor:** High **False Positive Probability:** 1 **Log Sources (minimum)** AI Engine Events **Log Sources (recommended)** N/A **AIE Rule Additional Details** This rule looks for AIE Feedback events which move through the Attack Lifecycle stages. There will always be a Host (Impacted), Host (Origin), or User (Origin) in common. Drilling down on this alarm will return the AIE events which triggered it. Drill down on those events to return the underlying log data. Run an investigation for the User or Host specified to look for related activity. --- version: "7.14.0" language: "en" --- # Understanding User Anomaly Scores The User Anomaly Score is a single number trying to tell a complex overall story. There are several different ways of computing this number. Ultimately, this single number cannot tell the whole story and may not satisfy every analyst or provide enough context for every scenario. For example, a simple average of the hourly Event Scores would be influenced by the absence of activity, by a high number of low scores, and would tend to disregard high scores. A conditioned average would tend to highlight high scores, and disregard lower noise. Using a maximum function would likely score everyone as 90+. It is also worth noting that a maximum function or something similar would eliminate the ability to identify the difference between a user with a single score of 99 during the 24-hour period and a user with multiple scores of 99 during the 24 hour period. Each behavior is scored every hour to produce an individual behavior score: | | b1 | b2 | b3 | b4 | b5 | | t0 | 87 | 2 | 19 | 32 | 99 | | t1 | 3 | 1 | 4 | 19 | 20 | | ... | ... | ... | ... | ... | ... | | ... | ... | ... | ... | ... | ... | | t23 | 1 | 3 | 65 | 17 | 5 | |-----|-----|-----|-----|-----|-----| The entire 24 hours of behavior scores is aggregated to produce the User Anomaly Score. We have chosen to use a conditioned mean for this aggregation. That is, the User Anomaly Score excludes numbers below a threshold, as well as excluding empty values. | User Anomaly Score | 37 | |--------------------|----| Behavior scores that do not reach a significant behavior and feature contribution threshold do not display in an Event Card, but they are still considered in the User Anomaly Score. For example, the following image shows a user with an overall User Anomaly Score of 11, but there are multiple high value Event Score cards. This occurs when there are many low-scoring behaviors which are included in the User Anomaly Score, but they are not high enough to warrant an Event Score card by themselves. ![event_scores.png](https://docs.logrhythm.com/__attachments/a_e68198e4d17c6828e9bb6266a705eb99d94af09d5b85a287e182f14205a53269/event_scores.png?cb=2639f164bde7046eba8d290dcdec985c) Each of the individual behaviors b1...b5 is comprised of a number of features. For example, f1...f7 are modeled (that is, we observe a baseline of the features that comprise a behavior and build a model based on this baseline). To produce a score for each behavior, the underlying features of that behavior are observed over an hour, and the observed values are compared against the values predicted by the model. The collective deviations are used to determine the anomaly score for that particular behavior. This is the number displayed on the Event Score cards: | | f1 | f2 | ... | ... | f7 | | Expected (modeled) | 30 | 2 | ... | ... | 1 | | Observed | 31 | 14 | ... | ... | 2 | |--------------------|----|----|-----|-----|----| The aggregated total of the evaluated features produces the behavior score that is displayed on the Event Score card. In this example, the score is 99. The system also assesses how much each of the individual features contributed towards the overall behavior score, and the feature descriptions that made a meaningful contribution are used for the Event Scores of that behavior type in the Event Score cards. While there is only one score of 99 in the table above, that score may be surfaced in the timeline multiple times. In the following example, the behavior score related to Common Events is predominantly made up of three different features: Large Number of, Unusual Distribution of, and Unusual Number of. Each of these features contributes a meaningful proportion of the ultimate behavior score. There may be other features that contribute to that score, but that contribution is either minimal or negligible. The following is an example of what the timeline might display: ![event_card_2.png](https://docs.logrhythm.com/__attachments/a_f6629b391cc86860e941bd6b56a6c30a3ada1b62dbb05a32c4b39079d42ecd01/event_card_2.png?cb=37816e24cf2a2d7ee7ee4ec7ee52b402) Even though there are three 99 Event Scores, they are all related to the same behavior (indicated by the icon on each card ![event_card_icon.png](https://docs.logrhythm.com/__attachments/a_500c842ef0177d7a69ad855706816a5a8ee1271a2af725d0f6c4db0d5e6c7b7b/event_card_icon.png?cb=27176983af2246ab47f9adbe8d07e367) ). There is no way to tell from the CloudAI interface how much each feature contributed, only that they all contributed significantly to that score. Internally, we assume them all to be events (individually and collectively). Every Event Score card displays an observed and expected number. Do not be tempted to focus on the observed and expected numbers simply because they seem more tangible, where the Event Score might seem more ephemeral. The Event Score is, in fact, much more important, and the observed and expected numbers may be misleading in some cases. ## Score Summary Given all factors, a single very anomalous activity in one hour tends to drive up the overall User Anomaly Score, but that depends on what else has changed or remained the same. This is how a conditioned mean works. The score shows how anomalous a user's overall behavior is today compared to their own behavior (and peers) over the past thirty days. One user action (for example, a login from a different geographical location) may be significantly different, and the Event Score for that behavior for that hour reflects that fact. If the user had no other Event Scores in the day, the User Anomaly Score would be high, but if they had many other low scoring behaviors, that would tend to draw the User Anomaly Score down. ## Anomaly vs Threat LogRhythm UEBA (CloudAI) is LogRhythm's advanced UEBA solution that leverages machine learning analytics to perform anomaly detection. This solution is designed to complement and enhance the existing out of the box UEBA detection capabilities and KB content in the LogRhythm SIEM. CloudAI considers the threat risk relevances of the anomalies that it finds when calculating the user anomaly score, so the highest user score is not only the most anomalous but is also the user who represents the highest threat risk. ## New Users When a new user is added after the initial deployment, all of their activity shows as anomalous for the first day. In general, scores become more meaningful with a baseline of approximately 7 days, and ideally 14 days. This is the reason behind the Ignore list. It is not expected that the monitored users change often, so we allow visibility into the activity, but provide the Ignore list especially built to hide the results in the first few days. Each time a new user is added to the Monitored Identities List, there is no existing history for that user in CloudAI, and you must wait for 30 days before there is a baseline equivalent to the length of the baseline all other users have. For this reason, you should not take users in and out of CloudAI without very good reason, since a new baseline needs to be rebuilt each time. This situation for new users differs from the initial setup of CloudAI where no results are returned for 48 hours. This is because a 24 hour baseline must be built, followed by 24 hours of activity to compare to it before any results are available. --- version: "7.14.0" language: "en" --- # User and Entity Behavior Analytics – AI Engine Rules The following table describes the log source types that should be collected to make effective use of each AIE rule in the UEBA Module. | AIE Rule ID | AIE Rule Name | Log Sources (minimum) | Log Sources (recommended) | |-------------|--------------------------------------------------------------------|---------------------------------------------------------|---------------------------------------------| | 1245 | Attainment: Abnormal File Access | LogRhythm Sysmon | Other File Integrity Monitoring | | 1246 | Attainment: Corroborated Account Anomalies | AI Engine Events | AI Engine Events | | 1247 | C2: Abnormal Origin Location | Active Directory or LDAP | Host Logs | | 1248 | Compromise: Abnormal Process Activity | Host Logs | LogRhythm Sysmon | | 1249 | C2: Blacklist Location Auth | Active Directory or LDAP | Host Logs | | 1250 | Compromise: Concurrent VPN from Multiple Locations | Authentication Log Sources | N/A | | 1251 | Recon: Linux sudo Privilege Escalation | Linux Host Logs | Active Directory or LDAP | | 1252 | Compromise: Windows RunAs Privilege Escalation | Windows Host Logs | Active Directory or LDAP | | 1253 | Compromise: Auth After Numerous Failed Auths | Active Directory or LDAP | Host Logs | | 1254 | Compromise: Auth After Security Event | Intrusion Detection System Host Logs | Intrusion Detection System LogRhythm Sysmon | | 1255 | Compromise: Distributed Brute Force | Active Directory or LDAP | Host Logs, Web Server Logs | | 1256 | Compromise: External Brute Force Auths | Active Directory or LDAP | Host Logs, Web Server Logs, VPN | | 1257 | Compromise: Lateral Movement With Account Sweep | Active Directory or LDAP | Host Logs | | 1258 | Corruption: Audit Disabled by Admin | Host Logs | LogRhythm Sysmon | | 1259 | Disruption: Files Deleted by Admin | Host Logs | Active Directory or LDAP, LogRhythm Sysmon | | 1260 | Lateral: Abnormal Auth Behavior | Active Directory or LDAP | Host Logs | | 1261 | Compromise: Account Added to Admin Group | Active Directory or LDAP | Host Logs | | 1262 | Lateral: Admin Password Modified | Active Directory or LDAP | Host Logs | | 1263 | Lateral: Auth After Dispersed Failed Auths | Active Directory or LDAP | Host Logs | | 1264 | Lateral: Brute Force Internal Auth Failure | Active Directory or LDAP | Host Logs | | 1265 | Lateral: External Attack then Account Creation | Active Directory or LDAP | Host Logs | | 1266 | Lateral: Failed Auths then Success | Active Directory or LDAP | Host Logs | | 1267 | Lateral: Internal Attack then Account Creation | Intrusion Detection System and Active Directory or LDAP | Intrusion Detection System and Host Logs | | 1268 | Lateral: Internal Recon then Account Creation | Intrusion Detection System and Active Directory or LDAP | Intrusion Detection System and Host Logs | | 1269 | Lateral: Multiple Account Passwords Modified by Admin | Active Directory or LDAP | Host Logs | | 1270 | Lateral: Numerous and Dispersed Internal Failed Auths | Active Directory or LDAP | Host Logs | | 1271 | Lateral: Numerous Internal Failed Auths | Active Directory or LDAP | Host Logs | | 1272 | Lateral: Password Modified by Admin | Active Directory or LDAP | Host Logs | | 1273 | Lateral: Privilege Escalation after Attack | Intrusion Detection System Host Logs | Intrusion Detection System LogRhythm Sysmon | | 1278 | Compromise: CloudAI Multiple User Threat Events | LogRhythm UEBA Events | N/A | | 1279 | Recon: Disabled Account Auth Failures | Active Directory or LDAP | Host Logs | | 1281 | Recon: Failed Distributed Account Probe | Active Directory or LDAP | Host Logs | | 1282 | Recon: Failed Distributed Brute Force | Active Directory or LDAP | Host Logs | | 1283 | Recon: Multiple Lockouts | Active Directory or LDAP | Host Logs | | 1284 | Progression: to Initial Compromise | AI Engine Events | N/A | | 1285 | Progression: to Command and Control | AI Engine Events | N/A | | 1286 | Progression: to Lateral Movement | AI Engine Events | N/A | | 1287 | Progression: to Target Attainment | AI Engine Events | N/A | | 1288 | Progression: to Exfil, Corruption, Disruption | AI Engine Events | N/A | | 1289 | Progression: to Initial Compromise | AI Engine Events | N/A | | 1290 | Progression: to Command and Control | AI Engine Events | N/A | | 1291 | Progression: to Lateral Movement | AI Engine Events | N/A | | 1292 | Progression: to Target Attainment | AI Engine Events | N/A | | 1293 | Progression: to Exfil, Corruption, Disruption | AI Engine Events | N/A | | 1294 | Progression: to Initial Compromise | AI Engine Events | N/A | | 1295 | Progression: to Command and Control | AI Engine Events | N/A | | 1296 | Progression: to Lateral Movement | AI Engine Events | N/A | | 1297 | Progression: to Target Attainment | AI Engine Events | N/A | | 1298 | Progression: to Exfil, Corruption, Disruption | AI Engine Events | N/A | | 1299 | Compromise: Log Cleared | Host Security Logs/AV/IDS/IPS | NextGen Firewall | | 1300 | Compromise: Security Event then Process Starting | Host Security Logs/AV/IDS/IPS | NextGen Firewall | | 1301 | Compromise: System Time Change | Host Security Logs/IDS/IPS | NextGen Firewall | | 1302 | Compromise: Unusual Auth then Unusual Process | Host Security Logs/AD/LDAP | LogRhythm Sysmon | | 1303 | Compromise: Security Event then Scheduled Task | Host Security Logs/AV/IDS/IPS | Sysmon/CarbonBlack | | 1304 | Lateral: Locally Created and Used | Host Security Logs | Single Sign On Logs | | 1305 | Compromise: Change to Host File | LogRhythm Sysmon: File Monitor | N/A | | 1306 | Disruption: Critical Windows Binaries Modified/Deleted | LogRhythm Sysmon: File Monitor | N/A | | 1307 | Compromise: CloudAI and Recent User Location Data Observed | LogRhythm UEBA Events | VPN Logs | | 1308 | Compromise: CloudAI and Location Watch List | LogRhythm UEBA Events | VPN Logs | | 1309 | Compromise: CloudAI and User Recently Added to a Privileged Group | LogRhythm UEBA Events/Active Directory or LDAP | Host Logs | | 1310 | Compromise: CloudAI and User related Security Classification Event | LogRhythm UEBA Events/Any Log Source | N/A | | 1312 | Compromise: CloudAI Threat Event | LogRhythm UEBA Events/Active Directory or LDAP | Host Logs | | 1336 | Compromise: CloudAI Threat Event and Identity Lists | LogRhythm UEBA Events/Active Directory or LDAP | Host Logs | | 1490 | Exfiltration: CloudAI and File (NGFW) Detection | CloudAI/NGFW | N/A | | 1491 | Exfiltration: CloudAI and Sensitive Data (NGFW) Detection | CloudAI/NGFW | N/A | --- version: "7.14.0" language: "en" --- # User and Entity Behavior Analytics – Lists The following table contains the lists that are included in the UEBA module. All of these lists can be configured in the LogRhythm environment. | List ID | List Name | |----------|-------------------------------------------------| | -2554 | Attack Lifecycle: Exfil, Corruption, Disruption | | -2553 | Attack Lifecycle: Target Attainment | | -2552 | Attack Lifecycle: Lateral Movement | | -2551 | Attack Lifecycle: Command and Control | | -2550 | Attack Lifecycle: Initial Compromise | | -2549 | Attack Lifecycle: Recon and Planning | | -2363 | Network: Whitelisted Processes | | -2362 | Vulnerability Scanners | | -2180 | Network: Blacklisted Countries | | -2092 | Privileged Groups | | -2091 | Privileged Users | | -1000000 | CloudAI: Monitored Identities | | -1000001 | CloudAI: Ignore for 24 Hours | | -1000002 | Privileged Users | | -1000003 | Executive Users | | -1000004 | Watched Users | | -1000005 | Location Watch List | The following table indicates other KB modules which also use the Lists included with the UEBA Module. | ListID | List Name | KB Module Name | |--------|-------------------------------------------------|-----------------------------------| | -2092 | Privileged Groups | User Threat Detection | | -2092 | Privileged Groups | CIS Critical Security Controls | | -2180 | Network: Blacklisted Countries | User Threat Detection | | -2180 | Network: Blacklisted Countries | UCF Automation Suite | | -2180 | Network: Blacklisted Countries | Network Threat Detection | | -2180 | Network: Blacklisted Countries | Compliance Automation Suite: GDPR | | -2180 | Network: Blacklisted Countries | CIS Critical Security Controls | | -2362 | Vulnerability Scanners | UCF Automation Suite | | -2362 | Vulnerability Scanners | Network Threat Detection | | -2362 | Vulnerability Scanners | Endpoint Threat Detection | | -2362 | Vulnerability Scanners | Compliance Automation Suite: GDPR | | -2363 | Network: Whitelisted Processes | Endpoint Threat Detection | | -2549 | Attack Lifecycle: Recon and Planning | User Threat Detection | | -2549 | Attack Lifecycle: Recon and Planning | Network Threat Detection | | -2549 | Attack Lifecycle: Recon and Planning | Endpoint Threat Detection | | -2549 | Attack Lifecycle: Recon and Planning | Core Threat Detection | | -2550 | Attack Lifecycle: Initial Compromise | User Threat Detection | | -2550 | Attack Lifecycle: Initial Compromise | Network Threat Detection | | -2550 | Attack Lifecycle: Initial Compromise | Endpoint Threat Detection | | -2550 | Attack Lifecycle: Initial Compromise | Core Threat Detection | | -2551 | Attack Lifecycle: Command and Control | User Threat Detection | | -2551 | Attack Lifecycle: Command and Control | Network Threat Detection | | -2551 | Attack Lifecycle: Command and Control | Endpoint Threat Detection | | -2551 | Attack Lifecycle: Command and Control | Core Threat Detection | | -2552 | Attack Lifecycle: Lateral Movement | User Threat Detection | | -2552 | Attack Lifecycle: Lateral Movement | Network Threat Detection | | -2552 | Attack Lifecycle: Lateral Movement | Endpoint Threat Detection | | -2552 | Attack Lifecycle: Lateral Movement | Core Threat Detection | | -2553 | Attack Lifecycle: Target Attainment | User Threat Detection | | -2553 | Attack Lifecycle: Target Attainment | Network Threat Detection | | -2553 | Attack Lifecycle: Target Attainment | Endpoint Threat Detection | | -2553 | Attack Lifecycle: Target Attainment | Core Threat Detection | | -2554 | Attack Lifecycle: Exfil, Corruption, Disruption | User Threat Detection | | -2554 | Attack Lifecycle: Exfil, Corruption, Disruption | Network Threat Detection | | -2554 | Attack Lifecycle: Exfil, Corruption, Disruption | Endpoint Threat Detection | | -2554 | Attack Lifecycle: Exfil, Corruption, Disruption | Core Threat Detection | --- version: "7.14.0" language: "en" --- # User and Entity Behavior Analytics Module To avoid a data breach, your organization must detect and respond quickly to anomalous activity. User and entity behavior analytics (UEBA) can help you monitor for known threats and behavioral changes in user data, providing critical visibility to uncover user-based threats that might otherwise go undetected. LogRhythm UEBA module and CloudAI: * Use metadata processed by the SIEM from diverse sources to provide clean sets for effective analytics. * Offer a true view of the identity of users and hosts --- not just disparate identifiers. * Detect potential threats by applying full-spectrum analytics * Seamlessly integrate with the other LogRhythm tools so you can streamline the response using integrated playbooks, guided workflows, and approval-driven task automation. The User and Entity Behavior Analytics Module (UEBAM) is a collection of AI Engine rules (deterministic rules) designed to detect potential malicious user activity that is occurring within your organization. CloudAI is an advanced UEBA solution that leverages machine learning (ML) to perform anomaly detection in order to surface potential threats that could otherwise go undetected due to its complexity. The UEBA Module contains licensed content that is available only to customers with a valid subscription. ## Module Revisions The following table summarizes the changes that have been made since the last release (v2) of the User and Entity Behavior Module. | AIE Rule ID | AIE Rule Name | |-------------|-----------------------------------------------------------------------| | **New** || | 1490 | Exfiltration: CloudAI and File (NGFW) Detection | | 1491 | Exfiltration: CloudAI and Sensitive Data (NGFW) Detection | | **Modified** || | 1245 | Attainment: Abnormal File Access | | 1246 | Attainment: Corroborated Account Anomalies | | 1247 | C2: Abnormal Origin Location | | 1248 | Compromise: Abnormal Process Activity | | 1249 | C2: Blacklist Location Auth | | 1250 | Compromise: Concurrent Authentication Success from Multiple Locations | | 1251 | Recon: Linux sudo Privilege Escalation | | 1252 | Compromise: Windows RunAs Privilege Escalation | | 1253 | Compromise: Auth After Numerous Failed Auths | | 1254 | Compromise: Auth After Security Event | | 1255 | Compromise: Distributed Brute Force | | 1256 | Compromise: External Brute Force Auths | | 1257 | Compromise: Lateral Movement With Account Sweep | | 1258 | Corruption: Audit Disabled by Admin | | 1259 | Disruption: Files Deleted by Admin | | 1260 | Lateral: Abnormal Auth Behavior | | 1261 | Compromise: Account Added to Admin Group | | 1262 | Lateral: Admin Password Modified | | 1263 | Lateral: Auth After Dispersed Failed Auths | | 1264 | Lateral: Brute Force Internal Auth Failure | | 1265 | Lateral: External Attack then Account Creation | | 1266 | Lateral: Failed Auths then Success | | 1267 | Lateral: Internal Attack then Account Creation | | 1268 | Lateral: Internal Recon then Account Creation | | 1269 | Lateral: Multiple Account Passwords Modified by Admin | | 1270 | Lateral: Numerous and Dispersed Internal Failed Auths | | 1271 | Lateral: Numerous Internal Failed Auths | | 1272 | Lateral: Password Modified by Admin | | 1273 | Lateral: Privilege Escalation after Attack | | 1278 | Compromise: CloudAI Multiple User Threat Events | | 1279 | Recon: Disabled Account Auth Failures | | 1281 | Recon: Failed External Auth to Multiple Hosts | | 1282 | Recon: Failed External Auth from Multiple Hosts | | 1283 | Recon: Multiple Lockouts | | 1284 | Progression: to Initial Compromise | | 1285 | Progression: to Command and Control | | 1286 | Progression: to Lateral Movement | | 1287 | Progression: to Target Attainment | | 1288 | Progression: to Exfil, Corruption, Disruption | | 1289 | Progression: to Initial Compromise | | 1290 | Progression: to Command and Control | | 1291 | Progression: to Lateral Movement | | 1292 | Progression: to Target Attainment | | 1293 | Progression: to Exfil, Corruption, Disruption | | 1294 | Progression: to Initial Compromise | | 1295 | Progression: to Command and Control | | 1296 | Progression: to Lateral Movement | | 1297 | Progression: to Target Attainment | | 1298 | Progression: to Exfil, Corruption, Disruption | | 1299 | Compromise: Log Cleared | | 1300 | Compromise: Security Event then Process Starting | | 1301 | Compromise: System Time Change | | 1302 | Compromise: Unusual Auth then Unusual Process | | 1303 | Compromise: Security Event then Scheduled Task | | 1304 | Lateral: Locally Created and Used | | 1305 | Compromise: Change to Host File | | 1306 | Disruption: Critical Windows Binaries Modified/Deleted | | 1307 | Compromise: CloudAI and Recent User Location | | 1308 | Compromise: CloudAI and Location Watch List | | 1309 | Compromise: CloudAI and User Recently Added to a Privileged Group | | 1310 | Compromise: CloudAI and User related Security Classification Event | | 1336 | Compromise: CloudAI Threat Event and Identity Lists | | **Unchanged** || | 1312 | Compromise: CloudAI Threat Event | | **Removed** || | N/A || --- version: "7.14.0" language: "en" --- # User and Entity Behavior Analytics Module Deployment Guide This guide describes how to deploy the LogRhythm UEBAM. It is for LogRhythm administrators who handle the security of their organization's infrastructure and for anyone installing and configuring the SIEM. ## Module Contents This module includes: * 65 AI Engine Rules * 17 Lists ## Prerequisites The deployment of this module assumes the following: * The overall LogRhythm deployment is in a fully-developed state and is healthy. * The LogRhythm version is 7.3.1 or higher. * The TrueIdentity feature is fully configured. * LogRhythm's CloudAI feature is fully configured and integrated with your on-premises LogRhythm deployment. ## Overview of Steps This guide is divided into the following sections: * [UEBA Deployment Guide -- Upgrade Considerations](https://docs.logrhythm.com/ueba/docs/ueba-deployment-guide-upgrade-considerations.md) * [UEBA Deployment Guide -- Import and Synchronize the Module](https://docs.logrhythm.com/ueba/docs/ueba-deployment-guide-import-and-synchronize-the-module.md) * [UEBA Deployment Guide -- Configure the Module](https://docs.logrhythm.com/ueba/docs/ueba-deployment-guide-configure-the-module.md) --- version: "7.14.0" language: "en" --- # User and Entity Behavior Analytics Module User Guide The User and Entity Behavior Analytics (UEBA) Module is a collection of AI Engine rules designed to detect unusual or malicious user activity that is occurs within your organization's network The UEBA Module contains licensed content that is available only to registered customers with a valid subscription. ## Prerequisites This guide assumes the following: * The UEBA Module has been imported and the necessary AI Engine rules have been enabled following the steps in the User and Entity Behavior Analytics Module Deployment Guide. * Appropriate log sources, such as LogRhythm Sysmon, Windows Security Events, Firewalls, Intrusion Detection Systems, Anti-Virus and others have been configured to work with LogRhythm. * In order to identify internal and external sources for directional traffic, the network entity structure has been configured. * The LogRhythm Lists referenced by rules in this Module have been configured to the organization's environment. * The LogRhythm TrueIdentity feature is fully configured. Enabling the UEBA Module without configuring TrueIdentity may result in many false positive alarms. ## How to Use This Guide This guide is meant to be used as a day-to-day reference for the User and Entity Behavior Analytics Module content. All the content included in this module is listed here along with a detailed explanation, suggested response, and configuration and tuning notes. * *Suppression Multiple.* The Suppression Multiple, in conjunction with the Suppression Period, defines how much time must pass before the same AI Engine rule can be triggered again for the same set of criteria. * *Environmental Dependence Factor.* EDF is a high level quantification of how much effort is required in configuration and tuning for an AI Engine rule to perform as expected. This setting has no impact on processing. * *False Positive Probability.* The False Positive Probability is used in Risk-Based Priority (RBP) calculation for AI Engine Rules. It estimates how likely the rule is to generate a false positive response. A value of low indicates the pattern the rule matches is almost always a true positive. However, a value of high indicates the pattern the rule matches is very likely to be a false positive. Options range from 0 to 9 with: * 0 indicating the pattern the rule matched is almost always a true positive * 9 indicating the pattern the rule matched is very likely to be a false positive This guide includes the following section: * [UEBA User Guide -- AI Engine Rules](https://docs.logrhythm.com/ueba/docs/ueba-user-guide-ai-engine-rules.md) --- version: "7.14.0" language: "en" --- # Using LogRhythm UEBA CloudAI is now named LogRhythm UEBA. However, both names are referenced in our documentation. While the product name is now LogRhythm UEBA, the user interface (UI) continues to reference CloudAI. LogRhythm UEBA (CloudAI) functions as a log source type in the LogRhythm SIEM so you can create Event Dashboards, Analyze Dashboards, AIE Rules and integrate with Alarms, Cases and SmartResponses. The LogRhythm SIEM processes the UEBA anomaly detection outputs and parses information from the raw log (Logsourcetype: "LogRhythm CloudAI") into the applicable metadata. Example of a dashboard using "LogRhythm CloudAI" events in the LogRhythm SIEM: ![image2022-5-10_14-44-36.png](https://docs.logrhythm.com/__attachments/a_f9ccce8485cfa090a940070d23acd7a1cd2cb370c9850dddcc5db15ffba07a47/image2022-5-10_14-44-36.png?cb=a503e686d067cf091a3be935341e7d7d) Example of an alarm triggered by an AIE rule that uses "LogRhythm CloudAI" logs: ![image2022-5-10_14-45-39.png](https://docs.logrhythm.com/__attachments/a_04be2ad48ca33fee19a8d75feb0d55e8eec31a6681aea28a3c31d93d1f56f5af/image2022-5-10_14-45-39.png?cb=4894331f3837b7beeab9b15d45b8d7f2) --- version: "2023.10" language: "en" --- # LogRhythm Cloud ## Documentation * ### [Get Started with LogRhythm Cloud](https://docs.logrhythm.com/lrcloud/docs/get-started-with-logrhythm-cloud.md) ### [Cloud-to-Cloud Log Collection](https://docs.logrhythm.com/lrcloud/docs/cloud-to-cloud-log-collection.md) ### [LogRhythm Cloud User Guide](https://docs.logrhythm.com/lrcloud/docs/logrhythm-cloud-user-guide.md) ### [Find More Information](https://docs.logrhythm.com/lrcloud/docs/find-more-information.md) --- version: "2023.10" language: "en" --- # AI Engine LRCloud customers have the ability to create and enable Artificial Intelligence (AI) Engine rules, provided such rules do not cause resource constraints on the LogRhythm instance. If LogRhythm observes performance issues with the LogRhythm instance, LogRhythm will make reasonable efforts to work with the customer to either disable some of the rules and/or require the customer to tune the rules. To maintain the performance and stability of the instance, LogRhythm reserves the right to disable problematic rules. --- version: "2023.10" language: "en" --- # Alarms ## System Alarms System alarms, such as the silent log source alarms, are only visible in the Web Console as a restricted administrator user. They are not currently visible in the Client Console. --- version: "2023.10" language: "en" --- # API Log Sources The following API log sources are currently available: * Office 365 Message Tracking * AWS CloudTrail Events * AWS CloudWatch Events and Alarms * AWS Config Events * AWS Simple Storage Service (S3) Events * AWS S3 CloudTrail Events --- version: "2023.10" language: "en" --- # API Tokens Restricted Administrators do not have permission to generate API tokens. These API tokens are commonly used for connecting the Admin API, Case API, Threat Intelligence Service (TIS), Smart Response Plugins (SRPs), and the TrueIdentity Sync Client. To get an API token, the customer should open a support case. Tokens will be provided to customers through a one time Blacknote link for security purposes. --- version: "2023.10" language: "en" --- # APIs [LogRhythm's REST APIs](https://docs.logrhythm.com/docs/lrapi/rest-api) are available for LRCloud customers. The available routes and methods are used for a variety of administration, investigative, and search functions. To configure third-party applications to communicate with the REST Application Programming Interface (API), see [Register Third-Party Applications to Use the API](https://docs.logrhythm.com/docs/lrapi/rest-api/register-third-party-applications-to-use-the-api). To remove access, see [Disable Third-Party Applications for the API](https://docs.logrhythm.com/docs/lrapi/rest-api/disable-third-party-applications-for-the-api). LogRhythm currently offers the following REST APIs: * [Administration API](https://docs.logrhythm.com/docs/lrapi/rest-api/administration-api) * [AI Engine Cache Drilldown API](https://docs.logrhythm.com/docs/lrapi/rest-api/ai-engine-cache-drilldown-api) * [Alarm API](https://docs.logrhythm.com/docs/lrapi/rest-api/alarm-api) * [Case API](https://docs.logrhythm.com/docs/lrapi/rest-api/case-api) * [Metrics API](https://docs.logrhythm.com/docs/lrapi/rest-api/metrics-api) * [Search API](https://docs.logrhythm.com/docs/lrapi/rest-api/search-api) For support on how to use the API, see . In order to generate a bearer token for using any of the mentioned REST APIs, the customer should create a support case. The LogRhythm SOAP API is currently deprecated and not available in LRCloud. --- version: "2023.10" language: "en" --- # AWS CloudTrail Events API Collection AWS CloudTrail provides a management system that enables users to manage and deploy networks at geographically distributed locations. The System Monitor Agent can import CloudTrail events into LogRhythm for analysis. This document explains how to configure the collection of CloudTrail events using the Web Console's cloud-to-cloud functionality. This feature is available only to LRCloud customers. ## Prerequisites Before configuring collection from O365, do the following: * Make sure that the customer is an LRCloud customer and has their environment hosted. * Ensure that you have a valid AWS Access Key and Secret Access Key. ## Initialize the Logs Source 1. Log in to the Web Console as a Restricted Administrator User. 2. On the top navigation bar, click the **Administration** icon ![image2022-8-16_21-7-13.png](https://docs.logrhythm.com/__attachments/a_92d77c20c4dbe32a3968941618b65a94cde9e0f16a4bedc2c624f3330021634e/image2022-8-16_21-7-13.png?cb=c036abe17fbecd6cea18301006f00ba1) and select **Cloud Log Collection**. 3. At the top of the Cloud Log Collection page, click **New Log Source** . The New cloud log collection dialog box appears. 4. Select the **AWS CloudTrail Events** **SYSMON AGENT** tile. The Add AWS CloudTrail Events Log Source window appears. ![AWS CloudTrail Events.png](https://docs.logrhythm.com/__attachments/a_0e232afbc20ee422c7c0b5c2373c1af58da85b2d4450775ca059a76935f8a593/AWS%20CloudTrail%20Events.png?cb=d994b8612f94e257e63bf9219eb42175) 5. Enter the following details: | Setting | Description | |--------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Name | Enter the name for this log source. | | Description *(Optional)* | Enter a description for this log source. | | Region | Enter the endpoint region code for the specific AWS CloudTrail S3 bucket (for example, us-east-1). For more information, see [CloudTrail Regions and Endpoints](http://docs.aws.amazon.com/general/latest/gr/rande.html#ct_region). | | Access Key ID | Enter the AWS Access Key ID (for example, AKIAIOSFODNN7EXAMPLE). | | Secret Access Key | Enter the AWS Secret Access Key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY). | 6. Click **Save**. Once saved, the log source is auto-configured and will be available on the Log Sources tab in the Client Console. Collection should start automatically in few minutes. The Platform Manager hosts all the log sources. It is recommended to create a new host entity and move the log source to the new host. For security, the values entered are encrypted using LRCrypt. ## Default Configuration Values for AWS CloudTrail Events Log Source | Setting | Default Value | |-------------------------|---------------| | APIPollingIntervalInMs | 5000 | | APIRetryCount | 3 | | MaxResultCount | 50 | | StartupDelayInSeconds | 30 seconds | | NumberOfBackDaysData | 1 day | | NumberOfBackMinutesData | 40 minutes | | BackOffTime | 15 minutes | --- version: "2023.10" language: "en" --- # AWS CloudWatch Alarms API Collection Amazon CloudWatch is a monitoring service for AWS cloud resources and the applications that run on AWS. Amazon CloudWatch can be used to collect and track metrics, collect and monitor log files, and set alarms. Amazon CloudWatch can monitor AWS resources such as Amazon EC2 instances, Amazon DynamoDB tables, and Amazon RDS DB instances, as well as custom metrics generated by your applications and services. This document explains how to configure the collection of CloudTrail events using the Web Console's cloud-to-cloud functionality and is available only to LRCloud customers. ## Prerequisites Before configuring collection from AWS, do the following: * Make sure that the customer is an LRCloud customer and has their environment hosted. * Ensure that you have a valid AWS Access Key and Secret Access Key. ## Initialize the Logs Source 1. Log in to the Web Console as a Restricted Administrator User. 2. On the top navigation bar, click the **Administration** icon ![image2022-8-16_21-7-13.png](https://docs.logrhythm.com/__attachments/a_e0a7ba819216e61082acfa23d3afe1f4b651e0526aa8560183133522e9b79f5f/image2022-8-16_21-7-13.png?cb=c036abe17fbecd6cea18301006f00ba1) and select **Cloud Log Collection**. 3. At the top of the Cloud Log Collection page, click **New Log Source** . The New cloud log collection dialog box appears. 4. Select the **AWS CloudWatch Alarms** **SYSMON AGENT** tile. The Add AWS CloudWatch Alarms Log Source window appears. ![cloudwatch.png](https://docs.logrhythm.com/__attachments/a_36271d7a366ef8c813f02ed72d74e6b2d1ed7ab94fd1056a826163f04d022f27/cloudwatch.png?cb=5c4b86a71d7e80fe9b9ccf6445fb2f2e) 5. Enter the following details: | Setting | Default Value | Description | |---------------------------|----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Name | Not applicable | Enter the name for this log source. | | Description *(Optional)* | Not applicable | Enter a description for this log source. | | Region | Not applicable | Enter the endpoint region code for the specific AWS CloudTrail S3 bucket (for example, us-east-1). For more information, see [CloudTrail Regions and Endpoints](http://docs.aws.amazon.com/general/latest/gr/rande.html#ct_region). | | Access Key ID | Not applicable | Enter the AWS Access Key ID (for example, AKIAIOSFODNN7EXAMPLE). | | Secret Key Access Key | Not applicable | Enter the AWS Secret Access Key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY). | | Collect CloudWatch Alarms | true | If you do not want to collect Cloud Watch Alarms data, set this value to false. | | Collect CloudWatch Logs | true | If you do not want to collect Cloud Watch Logs data, set this value to false. | | CloudWatchLogGroupPrefix | all log groups | Specify which Log Groups you want to collect logs from. | 6. Click **Save**. A new active log source is created and accepted in the Client Console with the provided information. Collection should start automatically in few minutes. The Platform Manager hosts all the log sources. It is recommended to create a new host entity and move the log source to the new host. For security, the values entered are encrypted using LRCrypt. ## Default Configuration Values for AWS CloudWatch Alarms Log Source | Setting | Default Value | |------------------------|---------------| | APIPollingIntervalInMs | 5000 | | APIRetryCount | 3 | | MaxResultCount | 50 | | MaxResultCountLogs | 1000 | | StartupDelayInSeconds | 30 | --- version: "2023.10" language: "en" --- # AWS Config Events API Collection AWS Config is a fully managed service that provides an AWS resource inventory, configuration history, and configuration change notifications to enable security and governance. The System Monitor Agent can import AWS Config events into LogRhythm for analysis. This document explains how to configure the collection of AWS Config events using the Web Console's cloud-to-cloud functionality. This feature is available only to LRCloud customers. ## Prerequisites Before configuring collection from AWS, do the following: * Make sure that the customer is an LRCloud customer and has their environment hosted. * Ensure that you have a valid AWS Access Key and Secret Access Key. ## Initialize the Logs Source 1. Log in to the Web Console as a Restricted Administrator User. 2. On the top navigation bar, click the **Administration** icon ![image2022-8-16_21-7-13.png](https://docs.logrhythm.com/__attachments/a_9848f372e434f74f386d5b6ff3e3b7c5536dea0f338e5cbd3ce834000a2326c6/image2022-8-16_21-7-13.png?cb=c036abe17fbecd6cea18301006f00ba1) and select **Cloud Log Collection**. 3. At the top of the Cloud Log Collection page, click **New Log Source** . The New cloud log collection dialog box appears. 4. Select **AWS Config Events** **SYSMON AGENT** tile. The Add AWS Config Events Log Source window appears. ![AWS Config Events.png](https://docs.logrhythm.com/__attachments/a_a3ed6f17b16824d11f9a7e01aa881df4bfed6848eb9a3be2765c6304d4f0620d/AWS%20Config%20Events.png?cb=b28193bc1526d95007747186a1a0e1a5) 5. Enter the following details: | Setting | Default Value | Description | |--------------------------|----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Name | Not applicable | Enter the name for this log source. | | Description *(Optional)* | Not applicable | Enter a description for this log source. | | Region | Not applicable | Enter the endpoint region code for the specific AWS CloudTrail S3 bucket (for example, us-east-1). For more information, see [CloudTrail Regions and Endpoints](http://docs.aws.amazon.com/general/latest/gr/rande.html#ct_region). | | Access Key ID | Not applicable | Enter the AWS Access Key ID (for example, AKIAIOSFODNN7EXAMPLE). | | Secret Access Key | Not applicable | Enter the AWS Secret Access Key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY). | | Resource Type | ALL | List the Resource types that the Open Collector should collect. To collect from all resource types, use the value ALL; otherwise specify each value separated by a comma (,) without spaces. Possible Values: AWS::CloudTrail::Trail, AWS::EC2::CustomerGateway, AWS::EC2::EIP, AWS::EC2::InternetGateway, AWS::EC2::NetworkAcl, AWS::EC2::NetworkInterface, AWS::EC2::RouteTable, AWS::EC2::SecurityGroup, AWS::EC2::Subnet, AWS::EC2::Volume, AWS::EC2::VPC, AWS::EC2::VPNConnection, or AWS::EC2::VPNGateway. Example: ALL or AWS::EC2::Subnet,AWS::EC2::Volume,AWS::EC2::RouteTable. | 6. Click **Save**. A new active log source is created and accepted in the Client Console with the provided information. Collection should start automatically in few minutes. The Platform Manager hosts all the log sources. It is recommended to create a new host entity and move the log source to the new host. For security, the values entered are encrypted using LRCrypt. ## Default Config Values for AWS Config Events Log Source | Setting | Default Value | |-----------------------|---------------| | MaxResultCount | 100 | | StartupDelayInSeconds | 30 | --- version: "2023.10" language: "en" --- # AWS S3 Beat Collection This document explains how to initialize the AWS S3 Beat using cloud-to-cloud collection. This feature is available only to LRCloud customers. ## Prerequisites Before initializing the AWS S3 tracking beat using collection from Amazon, do the following: * Make sure that the customer is an LRCloud customer and has their environment hosted. * Check if Open Collector has been installed in the customer's LRCloud environment on a separate instance. If not, an Open Collector instance must be requested via a support case. * Ensure that the Open Collector log source has been accepted and configured for log source virtualization. * Check if you have the required keys: AWS Access Key, AWS Secret Access Key, and the SQS queue names. * Multiline pattern regex is not required to parse out logs. ## Apply the Log Source Virtualization Template 1. Log in to the Client Console in Cameyo. 2. Click **Deployment Manager** from the toolbar. 3. Click the **Log Sources** tab. 4. Double-click the required Open Collector Log Source (such as, {instance}-opencollector.c.e3-hub-753dd405.internal Open Collector). The Log Message Source Properties window appears. 5. Click the** Log Source Virtualization** tab. 6. If not checked, select the **Enable Virtualization** check box. 7. Click **Create Virtual Log Sources** . The Create Virtual Log Sources dialog box appears. 8. In the Virtual Log Sources menu, check the Action check box corresponding to the following items: * "Syslog - Open Collector - AWS S3" * "Syslog - Open Collector - AWS Guard Duty" * "Syslog - Open Collector -AWS Config Events" * "Syslog - Open Collector -AWS CloudWatch" * "Syslog - Open Collector -AWS CloudTrail" * "Syslog - Open Collector -AWS S3 CloudTrail" 9. Click  **Save.** The Virtual Log Source(s) created prompt appears. 10. Click **Ok**. 11. Click **Apply**. 12. Click **Ok** . The new Log Sources will appear in the grid as children of your parent log source. 13. Click the **System Monitors** tab. 14. Select the Action check box corresponding to the (customerid)-dpawc agent. 15. Right-click the selection, click **Actions** and then click **Service** **Restart**. ## Initialize the Beat 1. Log in to the Web Console as a Restricted Administrator User. 2. On the top navigation bar, click the **Administration** icon ![image2022-8-16_21-7-13.png](https://docs.logrhythm.com/__attachments/a_20803b09b2e663be6fb93d996987bf170044a5e585c14e80d58744a35a6cf17a/image2022-8-16_21-7-13.png?cb=c036abe17fbecd6cea18301006f00ba1) and select **Cloud Log Collection**. 3. At the top of the Cloud Log Collection page, click **New Log Source** . The New cloud log collection dialog box appears. 4. Select the **AWS S3 - Open Collector** tile. The Add Aws S3 Log Source window appears. ![image2022-6-28_12-55-1.png](https://docs.logrhythm.com/__attachments/a_e3ef5153f0052b022b78208a4eea60082b770f3ee25fa3d4bc3b84e8cde6fef5/image2022-6-28_12-55-1.png?cb=78669c94b2fdc32289b7ccf120b90ec0) 5. Enter the following details: | Setting | Description | |--------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Name | Enter the name for this log source. | | Description *(Optional)* | Enter a description for this log source. | | Access Key ID | The AWS access key (for example, ABCD12ABCDEF12ABCDEF). | | Secret Access Key | Enter the AWS secret access key (for example, aBDcef12AbDEF12/aBDcef12AbcDEF123ab/A1B2). | | SQS Queses | The SQS queue and region in the format: queuename:region For example, queue:us-east-2 If you want to monitor multiple queue name and region combinations, then it is suggested that you create multiple log sources. | 6. Click **Save**. 7. Log in to the Client Console in Cameyo. 8. Click **Deployment Manager** from the toolbar. 9. Click the **System Monitors** tab. 10. Select the Action check box corresponding to the dpwac agent. 11. Right-click the selection, click **Actions** and then click **Service** **Restart**. A new log source is created with the provided information based on the virtualized log source that was already created. Collection should start automatically in few minutes. The Open Collector hosts the log sources. It is recommended to create a new host entity and move the log source to the new host which is done in the log source properties screen and not from the log source grid. For security, the values entered are encrypted using LRCrypt. ## Default Config Values for AWS S3 Beat | Setting | Field Name | Default Value | |---------|------------------------|---------------------------------------------------------------------------------------------------------------------------------------| | 1. | AWSAccessKeyID | User-provided | | 2. | HeartbeatInterval | 5m0s | | 3. | HeartbeatDisabled | false | | 4. | AWSSecretAccessKey | User-provided | | 5. | traits.inclusion | Blank | | 6. | QueueList | User-provided | | 7. | traits.exclusion | Blank | | 8. | MaxKeys | 0 | | 9. | AWSFlag | false | | 10. | multiline.pattern | This feature is not currently in use for Cloud-to-Cloud collection. | | 11. | multiline.negate | false | | 12. | multiline.match | after | | 13. | assumeRoleArn | This flag is the Assume role ARN from AWS for cross account access in the format: arn:aws:iam::{Account-A-ID}:role/{Assume_role_name} | | 14. | assumeRoleFlag | false This flag enables a user to access cross-account logs retrieval using Sts:AssumeRole for AWS S3 Beat deployment. | | 15. | stsCredsExpirationTime | 1hr This flag sets the maximum session duration of the IAM role assigned to ARN used for the Assume role. | --- version: "2023.10" language: "en" --- # AWS S3 CloudTrail Events API Collection AWS CloudTrail provides a management system that enables users to manage and deploy networks at geographically distributed locations. Using the AWS S3 Flat File log source, the System Monitor Agent can collect CloudTrail logs from an S3 bucket that includes numerous logs from multiple regions and accounts. You can also collect logs recursively within a single S3 bucket (logs in subfolders). This document explains how to configure the collection of AWS S3 CloudTrail events using the Web Console's cloud-to-cloud functionality. This feature is available only to LRCloud customers. ## Prerequisites Before configuring collection from AWS, do the following: * Make sure that the customer is an LRCloud customer and has their environment hosted. * Ensure that you have a valid AWS Access Key and Secret Access Key. The cloud-to-cloud collection uses the AWS ListObjects API to collect logs from AWS S3 CloudTrail sources. The API may not return the full set of logs due to a known limitation in the AWS ListObject API. Requests for logs are returned in a series of transmissions using continuation tokens to keep track of previously collected files. Each continuation token returned by the API is based on the last file collected from the S3 bucket. This functionality can cause logs to be missed if new files added to the S3 bucket are placed before the last file collected from the last continuation token. ![ListOfFiles1.png](https://docs.logrhythm.com/__attachments/a_10a3ea1fed125e9e9c0fc8799cdf7b67592dd6effb019b5f65205d41faff609b/ListOfFiles1.png?cb=7954db2e1c5e597f397c2811ea0e94df) For more details on the ListObjects API functionality, see the following links to AWS documentation: [API List Objects Example 7](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjects.html#API_ListObjects_Example_7) [API List Objects Example 9](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html#API_ListObjectsV2_Example_9) ## Initialize the Logs Source 1. Log in to the Web Console as a Restricted Administrator User. 2. On the top navigation bar, click the **Administration** icon ![image2022-8-16_21-7-13.png](https://docs.logrhythm.com/__attachments/a_8f21c0312f101c2d28bf019b7ecab6fe477c3e15e518047e7339746e3d88ec54/image2022-8-16_21-7-13.png?cb=c036abe17fbecd6cea18301006f00ba1) and select **Cloud Log Collection**. 3. At the top of the Cloud Log Collection page, click **New Log Source** . The New cloud log collection dialog box appears. 4. Select the **AWS S3 CloudTrail** **SYSMON AGENT** tile. The Add AWS S3 CloudTrail Events Log Source window appears. ![s3 cloudtrail.png](https://docs.logrhythm.com/__attachments/a_7da1484d875b7bd167f09d467e545ae17851c18d3e0b6e704751e172f749feab/s3%20cloudtrail.png?cb=e721eef9c6d8862f3bd4c10a595872dc) 5. Enter the following details: | Setting | Description | |-----------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Region | The endpoint region code for the specific AWS CloudTrail S3 bucket (for example, us-east-1). For more information, see [Amazon S3 Regions and Endpoints](http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region). | | Access Key ID | Enter the AWS Access Key ID (for example, AKIAIOSFODNN7EXAMPLE). | | Secret Access Key | Enter the AWS Secret Access Key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY). | | Bucket Name | The name of the S3 bucket where logs are stored. | | Log Type | The type of log from which logs are being fetched (for example, CloudTrail or VPCFlowLogs). The log type is case-sensitive. For more information on VPC Flow Logs, see [VPC Flow Logs](https://docs.logrhythm.com/docs/devices/api-log-sources/api-aws-s3-cloudtrail-via-flat-file#APIAWSS3CloudTrail(viaFlatFile)-VPCFlowLogs). | | File Path | The absolute path for the log type defined in LogType setting. Example formats: AWSLogs/697238620699/CloudTrail/ AWSLogs/697238620699/VPCFlowLogs/ The file path is case-sensitive. | | Depth To Recurse | The depth of folders where logs are present. Examples: | Settings | Examples of File Path | |-----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | DepthToRecurse=1 FilePath=AWSLogs | AWSLogs/697238620698/ AWSLogs/697238620699/ | | DepthToRecurse=2 FilePath=AWSLogs | AWSLogs/697238620698/CloudTrail/ AWSLogs/697238620699/CloudTrail/ | | DepthToRecurse=3 FilePath=AWSLogs | AWSLogs/697238620698/CloudTrail/Region-1 AWSLogs/697238620698/CloudTrail/Region-2 AWSLogs/697238620698/CloudTrail/Region-3 AWSLogs/697238620699/CloudTrail/Region-1 AWSLogs/697238620699/CloudTrail/Region-2 AWSLogs/697238620699/CloudTrail/Region-3 | | | Exclusion Directories | One or more directories that you want to exclude from collection. If you want to exclude multiple directories, separate them with a comma. If you do not want to use this setting, leave it blank. Example scenario: Your AWS S3 bucket contains three directories, but you want to collect from only one of them. | Directories in Bucket | Setting | Directories Excluded | |-------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------|----------------------------------------------------------------------------------| | AWSLogs/697238620698/CloudTrail-Digest/ AWSLogs/697238620698/CloudTrail-Insight/ AWSLogs/697238620698/CloudTrail/ | ExclusionDirectories=CloudTrail-Digest,CloudTrail-Insight | AWSLogs/697238620698/CloudTrail-Digest/ AWSLogs/697238620698/CloudTrail-Insight/ | If you set ExclusionDirectories=CloudTrail, you will exclude all directories containing CloudTrail in their name. The directory name is case-sensitive. | | Inclusions | One or more file extensions that you want to collect (for example, \*.gz or \*.txt). If you want to include multiple file extensions, separate them with a comma (for example, \*.gz,\*.txt). You should not change the value for this field. | | Exclusions | One or more file extensions that you want to exclude from collection (for example, \*.gz or \*.txt). If you want to exclude multiple file extensions, separate them with a comma (for example, \*.gz,\*.txt). You should not change the value for this field. | 6. Click **Save**. A new active log source is created and accepted in the Client Console with the provided information. Collection should start automatically in few minutes. The Platform Manager hosts all the log sources. It is recommended to create a new host entity and move the log source to the new host. For security, the values entered are encrypted using LRCrypt. ## Default Config Values for AWS S3 Server Access Events Log Source | Setting | Default Value | |-----------------------|---------------| | NoOfBackDaysData | 1 | | LogApiRequests | false | | DataFolderFilesCount | 100 | | MaxQueueCount | 50000 | | MaxResultCount | 100 | | StartupDelayInSeconds | 30 | --- version: "2023.10" language: "en" --- # AWS S3 Server Access Events API Collection Amazon Simple Storage Service (Amazon S3) provides developers and IT teams with secure, durable, and highly scalable cloud storage. The System Monitor Agent can import Amazon S3 events into LogRhythm for analysis. This document explains how to configure the collection of Amazon S3 events using the Web Console's cloud-to-cloud functionality. This feature is available only to LRCloud customers. ## Prerequisites Before configuring collection from AWS, do the following: * Make sure that the customer is an LRCloud customer and has their environment hosted. * Ensure that you have a valid AWS Access Key and Secret Access Key. ## Initialize the Logs Source 1. Log in to the Web Console as a Restricted Administrator User. 2. On the top navigation bar, click the **Administration** icon ![image2022-8-16_21-7-13.png](https://docs.logrhythm.com/__attachments/a_50c730484bf03721d347591efa1207ce6c557783a75a152b04be02acf66f9360/image2022-8-16_21-7-13.png?cb=c036abe17fbecd6cea18301006f00ba1) and select **Cloud Log Collection**. 3. At the top of the Cloud Log Collection page, click **New Log Source** . The New cloud log collection dialog box appears. 4. Select the **AWS S3 Server Access SYSMON AGENT** tile. The Add AWS S3 Server Access Event Log Source window appears. ![s3 server access.png](https://docs.logrhythm.com/__attachments/a_8a1f56fb7e1acb6d98f03e44061ad8596795460c271ef924ffd4136519382c40/s3%20server%20access.png?cb=e4cedb2d707c80744a685aae92299c2b) 5. Enter the following details: | Setting | Description | |--------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Name | Enter the name for this log source. | | Description *(Optional)* | Enter a description for this log source. | | Region | Enter the endpoint region code for the specific AWS CloudTrail S3 bucket (for example, us-east-1). For more information, see [CloudTrail Regions and Endpoints](http://docs.aws.amazon.com/general/latest/gr/rande.html#ct_region). | | Access Key ID | Enter the AWS Access Key ID (for example, AKIAIOSFODNN7EXAMPLE). | | Secret Access Key | Enter the AWS Secret Access Key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY). | | Bucket Name | Enter the name of the bucket where logs are stored. | | Folder | Logs cannot be collected from the root folder of the AWS S3 bucket. Before collection, there should to be a "logs" folder in the target bucket. All the files must be copied into that new folder (for example, 'logs/'). | 6. Click **Save**. A new active log source is created and accepted in the Client Console with the provided information. Collection should start automatically in few minutes. The Platform Manager hosts all the log sources. It is recommended to create a new host entity and move the log source to the new host. For security, the values entered are encrypted using LRCrypt. ## Default Config Values for AWS S3 Server Access Events Log Source | Setting | Default Value | |-----------------------|---------------| | MaxResultCount | 100 | | StartupDelayInSeconds | 30 | --- version: "2023.10" language: "en" --- # Azure Event Hub Beat Collection This document explains how to initialize the Azure Event Hub Beat using the Web Console's cloud-to-cloud functionality. This feature is available only to LRCloud customers. ## Prerequisites Before initializing the Azure Event Hub Beat, do the following: * Make sure that the customer is an LRCloud customer and has their environment hosted. * Check if the Open Collector has been installed in the customer's LRCloud environment on a separate instance. If not, an Open Collector instance must be requested via a support case. * Ensure that the Open Collector log source has been accepted. * Check if you have the required strings from Azure. ## Apply the Log Source Virtualization Template 1. Log in to the Client Console in Cameyo. 2. Click **Deployment Manager** from the toolbar. 3. Click the **Log Sources** tab. 4. Double-click the required Open Collector Log Source (such as, {instance}-opencollector.c.e3-hub-753dd405.internal Open Collector). The Log Message Source Properties window appears. 5. Click the** Log Source Virtualization** tab. 6. If not checked, select the **Enable Virtualization** check box. 7. Click **Create Virtual Log Sources** . The Create Virtual Log Sources dialog box appears. 8. In the Virtual Log Sources menu, check the Action check box corresponding to the "Syslog - Open Collector - Azure Event Hub" log source type. 9. Click  **Save.** The Virtual Log Source(s) created prompt appears. 10. Click **Ok**. 11. Click **Apply**. 12. Click **Ok** . The new Log Sources will appear in the grid as children of your parent log source. 13. Click the **System Monitors** tab. 14. Select the Action check box corresponding to the (customerid)-dpawc agent. 15. Right-click the selection, click **Actions** and then click **Service** **Restart**. ## Initialize the Beat 1. Log in to the Web Console as a Restricted Administrator User. 2. On the top navigation bar, click the **Administration** icon ![image2022-8-16_21-7-13.png](https://docs.logrhythm.com/__attachments/a_c4cc05243d193225f80f13f7dfe8cef0e5a39cc55bba1cf1b6b8d5c966a8f029/image2022-8-16_21-7-13.png?cb=c036abe17fbecd6cea18301006f00ba1) and select **Cloud Log Collection**. 3. At the top of the Cloud Log Collection page, click **New Log Source** . The New cloud log collection dialog box appears. 4. Select the **Azure Event Hub - Open Collector** tile. The Add Azure Event Hub Log Source window appears. ![azure.png](https://docs.logrhythm.com/__attachments/a_ec9365252a90ce16d726dfc63da5d0f6d9a8d30150f0d3a97f1ea8561e65a12b/azure.png?cb=6f00b7d36a2f9d4c7b5ff92ce3750386) 5. Enter the following details: | Setting | Description | |---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Name | Enter the name for this log source. | | Description *(Optional)* | Enter a description for this log source. | | Storage Connection String | Enter the Azure storage account connection string. The Storage Account Connection String is in the following format: `DefaultEndpointsProtocol=https;AccountName={StorageAccountName};AccountKey={Key};EndpointSuffix=core.windows.net` | | Connection String | Enter the Event Hub connection string followed by a comma, and then the storage container name. A storage container will be created if it is not already configured. The Event Hub Connection Strings are in the following format: `Endpoint=sb://{EventHubNamespace}.servicebus.windows.net/;SharedAccessKeyName={PolicyName};SharedAccessKey={Key};EntityPath={EventHub},containername` | 6. Click **Save**. 7. Log in to the Client Console in Cameyo. 8. Click **Deployment Manager** from the toolbar. 9. Click the **System Monitors** tab. 10. Select the Action check box corresponding to the dpwac agent. 11. Right-click the selection, click **Actions** and then click **Service** **Restart**. A new log source is created with the provided information based on the virtualized log source that was already created. Collection should start automatically in few minutes. The Open Collector hosts the log sources. It is recommended to create a new host entity and move the log source to the new host which is done in the log source properties screen and not from the log source grid. For security, the values entered are encrypted using LRCrypt. ## Default Config Values for Azure Event Hub Beat | Setting | Field Name | Default Value | |---------|-------------------|---------------| | 1 | period | 1s | | 2 | HeartbeatInterval | 5m 0s | | 3 | HeartbeatDisabled | false | | 4 | Time Period | 5s | | 5 | Azure Flag | false | --- version: "2023.10" language: "en" --- # Backups The LRCloud team ensures data retention, backups, and maintenance efforts. For more information, see [https://logrhythm.com/about/logrhythm-terms-and-conditions](https://logrhythm.com/about/logrhythm-terms-and-conditions/). --- version: "2023.10" language: "en" --- # Beat Log Sources The following beat log sources are currently available: * AWS S3 beat * Azure Event Hub beat * Gmail Message Tracking Beat * PubSub (GCP) Beat * Sophoscentral Beat * CiscoAMP Beat * Duo Beat * Carbonblack Cloud Beat * Okta Beat --- version: "2023.10" language: "en" --- # Cameyo ## Access the Client Console The LogRhythm Client Console is accessible through Cameyo. Cameyo provides an experience similar to remote desktop protocol (RDP) through an HTTPS-secured HTML5 web application. To access Cameyo, go to [https://logrhythm.cameyo.com](https://logrhythm.cameyo.com/). Users can log into Cameyo using either an O365 or Google account. Local accounts such as Active Directory or on-prem exchange cannot be used for Cameyo authentication. The LRCloud team must grant the necessary permissions to this account to access the customer's corresponding environment. Once the user is able to log into Cameyo, they will be presented with a tile. When the user selects the tile, the Client Console log-in screen appears. ![image2022-3-17_15-22-53.png](https://docs.logrhythm.com/__attachments/a_27301255ef1218860c99e07bf7072df58da8e5eba4a317a7c2bd2ab665af4f25/image2022-3-17_15-22-53.png?cb=08062e2146c15f153eb2e5c81d885b5f) **How to close a Cameyo session:** To exit from the LogRhythm Client Console, click **File** and then click**Exit** within the Client Console or click the Close icon at the top-right corner of the Console. This initiates a proper shutdown of the Cameyo session. It is not advised to directly close the browser tabs or the application window. ## Cameyo Licensing SQL licensing in LRCloud is not based on server+CAL. The LRCloud user counts are based specifically on Cameyo licensing for Client Console access (technically, Windows CALs). This is tracked and paid through Cameyo licensing. Customers need to purchase a license for each Client Console/Cameyo user. Customers receive few Cameyo licenses as part of their LogRhythm Cloud subscription. The number of licenses vary based on their purchase volume. * 1k -4k MPS: 2 users * 5k -- 10k MPS: 3 users * 10K - 29K MPS: 5 users * 30K - 74K MPS: 10 users * 75K - 199K MPS: 15 users * 200K+ MPS: 20 users If the number of licenses included in the LogRhythm Cloud subscription is not enough, the customer can purchase more by contacting their Customer Success Manager. Cameyo only supports commercial Microsoft O365 and Google Cloud Provider (GCP). GCP high encryption is not supported for Cameyo sign in. --- version: "2023.10" language: "en" --- # Carbon Black Cloud Beat Collection This document explains how to initialize Carbon Black Cloud Beat using cloud-to-cloud collection after configuration. It is primarily focused on the alert log to be pulled from the Carbon Black Cloud console. This feature is available only to LRCloud customers. ## Prerequisites Before initializing Carbon Black Cloud Beat, do the following: * Make sure that the customer is an LRCloud customer and has their environment hosted. * Check if Open Collector has been installed in the customer's LRCloud environment on a separate instance. If not, an Open Collector instance must be requested via a support case. * Ensure that the Open Collector log source has been accepted. * Check if you have the Carbon Black Cloud console hostname. You should have received the hostname when you purchased the Carbon Black Cloud platform. For more information on hostname, see . * Make sure that you have the Carbon Black Cloud console API Credentials and Organization key. If you do not have the required details, follow the instructions in [Configure API Access on Carbon Black Cloud Console](https://docs.logrhythm.com/docs/OCbeats/carbon-black-cloud-beat/configure-carbon-black-cloud). * Ensure that you have a sensor installed in one of your machines to sync the alerts on the Carbon Black Cloud console. This sensor can be installed using the Sensor option provided under Endpoints in the Carbon Black Cloud console. ## Apply the Log Source Virtualization Template 1. Log in to the Client Console in Cameyo. 2. Click **Deployment Manager** from the toolbar. 3. Click the **Log Sources** tab. 4. Double-click the required Open Collector Log Source (such as, {instance}-opencollector.c.e3-hub-753dd405.internal Open Collector). The Log Message Source Properties window appears. 5. Click the** Log Source Virtualization** tab. 6. If not checked, select the **Enable Virtualization** check box. 7. Click **Create Virtual Log Sources** . The Create Virtual Log Sources dialog box appears. 8. In the Virtual Log Sources menu, check the Action check box corresponding to "Syslog - Open Collector - Carbon Black Cloud" and "Syslog - Open Collector - CarbonBlackBeat Heartbeat" log source types. 9. Click  **Save.** The Virtual Log Source(s) created prompt appears. 10. Click **Ok**. 11. Click **Apply**. 12. Click **Ok** . The new Log Sources will appear in the grid as children of your parent log source. 13. Click the **System Monitors** tab. 14. Select the Action check box corresponding to the (customerid)-dpawc agent. 15. Right-click the selection, click **Actions** and then click **Service** **Restart**. ## Initialize the Beat 1. Log in to the Web Console as a Restricted Administrator User. 2. On the top navigation bar, click the **Administration** icon ![image2022-8-16_21-7-13.png](https://docs.logrhythm.com/__attachments/a_7cbfdd497b70b8046f335ab272bc4aec99e298e981b86becf398367d37ea8e93/image2022-8-16_21-7-13.png?cb=c036abe17fbecd6cea18301006f00ba1) and select **Cloud Log Collection**. 3. At the top of the Cloud Log Collection page, click **New Log Source** . The New cloud log collection dialog box appears. 4. Select the **CarbonBlack Beat - Open Collector** tile. The Add CarbonBlack Beat Log Source window appears. ![carbonblack.png](https://docs.logrhythm.com/__attachments/a_5a1045968ce83e75bab8b821f6b5afd043fa8cd5077f373101462319e7428bc7/carbonblack.png?cb=5c5ec455dacca3d94b0dd1c61c098918) 5. Enter the following details: | Setting | Description | |--------------------------|-----------------------------------------------------------------------------------------------| | Name | Enter the name for this log source. | | Description *(Optional)* | Enter a description for this log source. | | Hostname | CarbonBlack cloud console hostname. Do not use "https://" from the original hostname. | | API ID | Enter the Carbon Black Cloud Platform API ID (for example, 12345678). | | Secret Key | Enter the Carbon Black Cloud Platform API Secret Key (for example, ABCDEFGHIJKLMNOPQRSTUVWX). | | Org Key | Enter the Carbon Black Cloud Platform Organization Key (for example, 1ABCD33E). | 6. Click **Save**. 7. Log in to the Client Console in Cameyo. 8. Click **Deployment Manager** from the toolbar. 9. Click the **System Monitors** tab. 10. Select the Action check box corresponding to the dpwac agent. 11. Right-click the selection, click **Actions** and then click **Service** **Restart**. A new log source is created with the provided information based on the virtualized log source that was already created. Collection should start automatically in few minutes. The Open Collector hosts the log sources. It is recommended to create a new host entity and move the log source to the new host which is done in the log source properties screen and not from the log source grid. For security, the values entered are encrypted using LRCrypt. ## Default Config Values for the Carbon Black Cloud Beat | Setting | Field Name | Default Values | |---------|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------| | 1 | heartbeatinterval | 60s | | 2 | heartbeatdisabled | false | | 3 | period | 2s | | 4 | numbackdaysData | 7 Number of back days must be a non-negative number. Only 180 days of backlog data is supported. Therefore, the range for this value is 1-180 days. | | 5 | limit | 1000 Supported limit range is 100-1000. | --- version: "2023.10" language: "en" --- # Cisco AMP Beat Collection This document explains how to initialize the Cisco AMP Beat using the Web Console's cloud-to-cloud functionality. This feature is available only to LRCloud customers. ## Prerequisites Before initializing the Cisco AMP Beat, do the following: * Make sure that the customer is an LRCloud customer and has their environment hosted. * Check if the Open Collector has been installed in the customer's LRCloud environment on a separate instance. If not, an Open Collector instance must be requested via a support case. * Ensure that the Open Collector log source has been accepted. * Check if you have the required keys: Cisco Client ID and API Key. ## Apply the Log Source Virtualization Template 1. Log in to the Client Console in Cameyo. 2. Click **Deployment Manager** from the toolbar. 3. Click the **Log Sources** tab. 4. Double-click the required Open Collector Log Source (such as, {instance}-opencollector.c.e3-hub-753dd405.internal Open Collector). The Log Message Source Properties window appears. 5. Click the** Log Source Virtualization** tab. 6. If not checked, select the **Enable Virtualization** check box. 7. Click **Create Virtual Log Sources** . The Create Virtual Log Sources dialog box appears. 8. In the Virtual Log Sources menu, check the Action check box corresponding to "Syslog - Open Collector - Cisco AMP" and "Syslog - Open Collector - CiscoAMPBeat Heartbeat" log source types. 9. Click  **Save.** The Virtual Log Source(s) created prompt appears. 10. Click **Ok**. 11. Click **Apply**. 12. Click **Ok** . The new Log Sources will appear in the grid as children of your parent log source. 13. Click the **System Monitors** tab. 14. Select the Action check box corresponding to the (customerid)-dpawc agent. 15. Right-click the selection, click **Actions** and then click **Service** **Restart**. ## Initialize the Beat 1. Log in to the Web Console as a Restricted Administrator User. 2. On the top navigation bar, click the **Administration** icon ![image2022-8-16_21-7-13.png](https://docs.logrhythm.com/__attachments/a_606eeffff1359cef9021b829371fc6d980a86b27dbed137a26ff447ed2e31cff/image2022-8-16_21-7-13.png?cb=c036abe17fbecd6cea18301006f00ba1) and select **Cloud Log Collection**. 3. At the top of the Cloud Log Collection page, click **New Log Source** . The New cloud log collection dialog box appears. 4. Select the **Azure Event Hub - Open Collector** tile. The Add CiscoAMP Beat Log Source window appears. ![ciscoamp.png](https://docs.logrhythm.com/__attachments/a_f4856f79149650b4af8433a20dbf017680ced50bd8ae0b5b2861ec180af8a860/ciscoamp.png?cb=49191332437bb46a28a829630114f69d) 5. Enter the following details: | Setting | Default Value | Description | |--------------------------|----------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Name | Not Applicable | Enter the name for this log source. | | Description *(Optional)* | Not Applicable | Enter a description for this log source. | | Client ID | Not Applicable | Enter the Cisco AMP EndPoint Client ID (for example, ab1234c123de123a45678a). | | API Key | Not Applicable | Enter the Cisco AMP EndPoint API Key (for example, ab1234ab-12ab-12ab-ab12-123456abcdef). | | URI Address | Not Applicable | Enter the Cisco AMP EndPoint URI address for the preferred region. API is location based and varies depending on where your AMP instance resides. Currently, three regions exist: | Region | Address | |---------------------------------|-------------------------------------------------------------------------------------------------------| | U.S. | [api.amp.cisco.com](https://api-docs.amp.cisco.com/api_versions?api_host=api.amp.cisco.com) | | Asia, Pacific, Japan, and China | [api.apjc.amp.cisco.com](https://api-docs.amp.cisco.com/api_versions?api_host=api.apjc.amp.cisco.com) | | Europe | [api.eu.amp.cisco.com](https://api-docs.amp.cisco.com/api_versions?api_host=api.eu.amp.cisco.com) | | | Event Types | All | List the Event log file types that the Open Collector should collect. To collect from all Event Log Types, use the value "ALL". Otherwise, specify each value separated by a comma (,) without spaces. For example: 554696715,1091567628,553648130. For more information on specific Event type IDs, see [https://api-docs.amp.cisco.com/api_actions/details?](https://api-docs.amp.cisco.com/api_actions/details?api_action=GET+%2Fv0%2Fevent_types&api_host=api.amp.cisco.com&api_resource=Event+Type&api_version=v0) | 6. Click **Save**. 7. Log in to the Client Console in Cameyo. 8. Click **Deployment Manager** from the toolbar. 9. Click the **System Monitors** tab. 10. Select the Action check box corresponding to the dpwac agent. 11. Right-click the selection, click **Actions** and then click **Service** **Restart**. A new log source is created with the provided information based on the virtualized log source that was already created. Collection should start automatically in few minutes. The Open Collector hosts the log sources. It is recommended to create a new host entity and move the log source to the new host which is done in the log source properties screen and not from the log source grid. For security, the values entered are encrypted using LRCrypt. ## Default Config Values for CiscoAMPBeat | Setting | Field Name | Default Value | |---------|--------------------------|---------------| | 1 | HeartbeatInterval | 60s | | 2 | HeartbeatDisabled | false | | 3 | Period | 4s | | 4 | limit | 250 | | 5 | numbackdaysDataAuditLogs | 7 | | 6 | numbackdaysData | 7 | | 7 | version | v1 | | 8 | throttlingIntervalSecs | 60 seconds | --- version: "2023.10" language: "en" --- # Cloud-to-Cloud Log Collection LogRhythm Cloud-to-Cloud (C2C) facilitates the creation, management, and collection of cloud log source information through a user interface in the Web Console. C2C credentials are used to provide a safe and secure collection method --- Open Collector with Beats or a System Monitor Agent. The following beat log sources are currently available: * AWS S3 beat * Azure Event Hub beat * Gmail Message Tracking Beat * PubSub (GCP) Beat * Sophoscentral Beat * CiscoAMP Beat * Duo Beat * Carbonblack Cloud Beat * Okta Beat The following API log sources are currently available: * Office 365 Message Tracking * AWS CloudTrail Events * AWS CloudWatch Events and Alarms * AWS Config Events * AWS Simple Storage Service (S3) Events * AWS S3 CloudTrail Events --- version: "2023.10" language: "en" --- # CloudAI and TrueIdentity ## Set up CloudAI The majority of CloudAI configuration is completed in advance by the LRCloud team. But, there are a few steps that the customer needs to complete. The setup steps are: 1. Open a support case requesting an LR API token to be used with the TrueIdentity Sync Client. 2. Install and launch TrueIdentity Sync Client on a server in the customer's environment with Active Directory access. 3. Create a TrueIdentity Sync Job using: 1. The API token requested 2. The API Endpoint URL: [https://CustomerName-api.logrhythm.cloud:443](https://customername-api.logrhythm.cloud/) * Do not forget to change the "CustomerName" in the URL to match the customer's environment. * The TrueIdentity Sync Client User Guide and the guidance in the Sync Client instructs users to add ":8501" or ":8505" to the end of their URL. Neither of these is accurate for LogRhythm Cloud customers as we use "443" instead. The TrueIdentity Sync Client requires a port number at the end of the string and will not allow a URL without it. 4. Create a list of monitored identities. Customers should use the Client Console to add users to the monitored identity list. At this time, the API and Web Console do not have permissions to add to this system list. [Next Page](https://docs.logrhythm.com/llms-full.txt/1)