A small business can configure useful security alerts without writing its own detection logic. Blue Lantern Security analyzes supported items and device checks, then lets an administrator choose which completed results should reach a person or an HTTPS destination.
There is still a setup decision: which findings matter, who should receive them, and how quickly they need attention. A notification becomes useful when its recipient knows what to do next.
This guide covers the URL, email, file, device, and AI Exposure run types that an alert rule can select. Identity and mail posture results are not selectable run types, so give them their own review routine in the Monitoring Hub.
What is built in, and what do you configure?
The platform performs its checks and analysis. An alert rule watches completed runs and matches the conditions you select. You are choosing when to deliver an existing result, rather than writing a query to detect a new attack pattern in raw logs.
Each rule has three main parts:
| Setting | What you decide |
|---|---|
| Filter | Run type, supported determination, and any minimum failed-check count |
| Destination | An email recipient or HTTPS endpoint |
| Timing | Immediate delivery or an hourly or daily digest |
Different filter fields must all match. For example, a URL rule with a Malicious determination and a minimum of three failed checks would require all three conditions. Leave the failed-check threshold empty if the intended rule is simply "send every Malicious URL result." Adding an unnecessary threshold can exclude results you meant to receive.
Start with one focused rule
Before configuring delivery, confirm that the relevant monitor or analysis workflow is producing results. An alert cannot report a scan that never ran.
As an account administrator, open Monitoring Hub, switch to Alerts, and select New Alert. Choose a clear name, the delivery type and destination, a timing option, and the filter conditions.
These are illustrative starting configurations, not preinstalled rules:
| Purpose | Run type | Determination | Failed-check threshold | Timing |
|---|---|---|---|---|
| Notify the reviewer of a malicious URL result | URL | Malicious | Leave empty | Immediate |
| Provide a retrying digest for the same URL results | URL | Malicious | Leave empty | Hourly |
| Review device findings that need prompt attention | Device | Critical | Leave empty | Immediate |
| Gather lower-severity device findings for review | Device | At Risk | Leave empty | Daily |
| Hear about newly appearing risky AI apps | AI Exposure | Critical or At Risk | Leave empty | Immediate |
Create each as a separate rule if it fits your process. The recipient should be someone authorized to see the findings and able to act or escalate. An inbox with nobody assigned to review it is an incomplete setup.
Device Critical is a posture verdict driven by failed checks, not a malware detection. For an AI Exposure run, a Critical or At Risk result means the scan flagged risky app grants, including apps that appear after the first baseline scan. The rule form labels the Critical and At Risk options for devices; the same values apply to AI Exposure runs. Open the report and interpret the underlying evidence before deciding the response.
Choose timing based on both urgency and delivery behavior
Immediate delivery happens after a matching run finishes. It is best-effort: a failed send is not retried, and duplicates are possible. An hourly or daily digest batches matches and retries failed delivery on a later schedule tick.
For important findings, a matching digest rule can supplement immediate delivery. The two rules will intentionally overlap, so tell the reviewer to expect the same result in both places. Retries improve delivery; a person still has to read the result and act.
Delivery timing is also separate from scan cadence. The device agent still checks about once an hour and the AI exposure scan still runs once a day; an immediate alert only changes how quickly a completed result reaches you.
Test the destination, then verify real matching behavior
Use Create & Send Test, or the Test action on an existing rule. The platform sends a synthetic notification marked as a test through the configured delivery channel.
Confirm that:
- The intended recipient or endpoint receives it.
- The message is accessible to the person responsible for review.
- The recipient knows where to find the associated reports and how to escalate.
- Any delivery error has been addressed before relying on the rule.
A synthetic test proves the channel works, not that your filters match real results, so review the configured conditions against actual completed runs. New rules watch from their creation time and do not backfill older findings.
Can these results go to a SIEM?
Yes, supported matching run summaries can be sent as JSON to an HTTPS destination. The destination must be set up to accept the payload and authentication you configure. Custom headers support endpoint authentication; keep those credentials in the appropriate configuration, not in a shared review document.
The platform Alerts documentation covers payload details and the Splunk HEC raw-endpoint arrangement. Delivery provides run summaries, not a general export of every event from the systems being monitored. The SIEM guide explains when broader log collection and search are needed.
Keep alert volume workable
Start with filters tied to a decision and review the resulting volume. A digest can list up to 100 runs and cover up to 500 matches per window under the documented limits; the alert indicates when a cap is exceeded. Use the Monitoring Hub for the complete set and tighten filters where appropriate.
If an alert is repeatedly ignored, review its purpose, recipient, and timing. Do not silently exclude a difficult finding just to make the inbox quieter. Record any accepted exception and when it should be revisited.
For device alerts, the device report walkthrough explains how to read the checks behind a verdict, and the AI exposure monitoring guide explains what a flagged app grant means. Start with one relevant rule in Monitoring Hub, test delivery, and give the reviewer a clear next action.