Logpoint Use Cases
| LP_LogPoint License Expiry Status | |
|---|---|
| Description | Triggers when there is one week until the license expires and subsequently alerts every day. |
| Log source | Logpoint |
| Value | A new license should be applied for immediately so that it can be applied before expiry and thereby avoid operational interruptions. In the case that the license has expired, alerts will still trigger after, but the GUI is inaccessible. |
| Query |
Copy
|
| Comments | Renew license at https://license.logpoint.com/ |
| Type | Alert |
| LP_Default Harddisk Usage Status | |
|---|---|
| Description | Triggered when hard disk usage reaches +80%. |
| Log source | Logpoint |
| Value | It is important to have a correct sizing of hardware so that the log volume does not take up more than 80% of disk space as this can affect performance. |
| Query | Copy |
| Comments | Alerts on all mount points. |
| Type | Alert |
| LP_Default CPU Usage Status | |
|---|---|
| Description | Triggers when CPU consumption reaches over 90%. |
| Log source | Logpoint |
| Value | It is important not to use more than 90% of the CPU, as a high resource consumption can lead to reduced system performance, which can compromise the effectiveness of monitoring and the timely handling of security incidents. |
| Query |
Copy
|
| Comments | - |
| Type | Alert |
| LP_Default Memory Usage Status | |
|---|---|
| Description | Triggers when RAM consumption reaches over 90%. |
| Log source | Logpoint |
| Value | It is important not to use more than 90% of the RAM, as a high resource utilization can lead to delays in the system for e.g. dashboards, which can compromise the effectiveness of monitoring. |
| Query |
Copy
|
| Comments | - |
| Type | Alert |
| LP_Default Device Stopped Sending Logs for Half an Hour | |
|---|---|
| Description | Triggered when a configured device has not sent logs for half an hour or more. This does not apply to log devices such as M365 or devices configured with Universal REST API fetchers(URAF). |
| Log source | All, except localhost or URAF devices |
| Value | This can help discover issues problems with log collection, which can create blind spots in security monitoring and possibly lead to failure to detect critical events. |
| Query |
Copy
|
| Comments | The time interval for alerting can be adjusted by changing the query value. Remember to take into account if you are collecting logs in batches with time interval greater than defined in the alert. |
| Type | Alert |
| M365 not Sending Logs | |
|---|---|
| Description | Triggered when logs from M365 stop being received. |
| Log source | Logpoint |
| Value | The default alarm for devices that do not send logs does not work on M365, as this is configured as a fetcher on the localhost device. |
| Query |
Copy
|
| Comments | The search interval must be longer than the fetch interval. |
| Type | Alert |
| Universal Rest Api Fetcher Devices not Sending Logs | |
|---|---|
| Description | Triggers when logs are stopped being fetched from API entities configured in the Universal REST API Fetcher(URAF). |
| Log source | REST API |
| Value | The default alert monitoring devices not sending logs, does not work on API devices, as these are configured with Universal REST API Fetcher. |
| Query |
Copy
|
| Comments | Requires that you have created the table used in advance and configured the associated SOAR playbook. |
| Type | Alert |
| Universal Rest Api Fetcher Devices not Sending Logs | |
|---|---|
| Description | Used for periodic updating the associated table to the alert 'Universal Rest Api Fetcher Devices not Sending Logs'. |
| Log source | API logs |
| Value | Automatically keeps your list of API endpoints up to date. |
| Query |
Copy
|
| Comments | In order to update the dynamic table, you must create a playbook with a 'query' block with the above query that searches against repos that contain API logs. Trigger must be set up as "Scheduled" and configured as needed. End with an 'End' block. |
| Type | Playbook |